CVS difference for ai05s/ai05-0024-1.txt

--- ai05s/ai05-0024-1.txt	2006/12/16 03:13:18	1.5
+++ ai05s/ai05-0024-1.txt	2007/05/19 05:10:26	1.6
@@ -1,4 +1,4 @@
-!standard 4.8(10/1)                                      06-11-13    AI05-0024-1/01
+!standard 4.8(10/1)                                07-05-18    AI05-0024-1/02
 !standard 3.10.2(14-14.3/2)
 !class binding interpretation 06-11-13
 !status work item 06-11-13
@@ -9,7 +9,15 @@
 !subject Run-time accessibility checks
 !summary
 
-TBD.
+Where appropriate, describe accessibility in terms of masters
+(dynamically) including a particular elaboration or evaluation,
+to solve prolems where there is a partial ordering rather than
+a full ordering between scopes (such as when tasking is involved).
+
+Handle some missing cases where an allocator is used to specify the
+value of an access discriminant, by saying that the level
+of the allocated object is the same as that of the master that elaborates
+the subtype_indication (or equivalently, that evaluates the allocator).
 
 !question
 
@@ -94,10 +102,81 @@
 
 !wording
 
-TBD.
+Add an AARM note after 3.10.2(29):
 
+    A check is made that the accessibility level of X is not deeper than that of
+    the access type A. If this check fails, Program_Error is raised.
+
+  {AARM NOTE: Because there are no access parameters permitted for task
+    entries, the accessibility levels are always comparable.  We would have to
+    switch to the terminology used in 4.8 and 6.5 based on inclusion within
+    masters if we relax this restriction.  That might introduce unacceptable
+    distributed overhead.}
+    
+Replace 3.10.2(14.1, 2, 3) as follows:
+
+  * for an allocator used to define the discriminant of an object, the level of
+    the object;
+    
+  * for an allocator used to define the constraint in a subtype_indication in
+    any other context, the level of the master that elaborates the
+    subtype_indication.
+    [TBD: Should we instead say: "...the master that evaluates the allocator"?]
+ 
+
+
+Change the first sentence of RM 4.8(10.1/2) to:
+
+    For any allocator, if the designated type of the type of the allocator is
+    class-wide, then a check is made that the master of the type determined by
+    the subtype_indication, or by the tag of the value of the
+    qualified_expression, includes the elaboration of the type of the allocator.
+    ...
+    
+Add an AARM Note after 4.8(10.1/2):
+  AARM NOTE: We can't use the normal accessibility level "deeper than" check
+    here because we may have "incomparable" levels.  This can happen when an
+    allocator initialized by a parameter passed in to an accept statement is
+    performed using an access type declared in the enclosing task body.
+
+Modify 6.5(8/2) as follows:
+
+    If the result type of a function is a specific tagged type, the tag of the
+    return object is that of the result type. If the result type is class-wide,
+    the tag of the return object is that of the value of the expression. A check
+    is made that the [accessibility level] {master} of the type identified by
+    the tag of the result [is not deeper than that of the master that
+    elaborated] {includes the elaboration of} the function body.  If this check
+    fails, Program_Error is raised.
+    
+ {AARM NOTE: We can't use the normal accessibility level "deeper than" check
+    here because we may have "incomparable" levels.  This can happen when an
+    accept statement calls a function declared in the enclosing task body, and
+    the function returns an object passed to it from the accept statement, and
+    this object was itself a parameter to the accept statement.}
+
+
 !discussion
 
+This AI really deals with two very separate issues. One is that
+under some circumstances, we may have "incomparable" accessibility
+levels. This happens when inside an accept statement, where the
+accessibility levels associated with the enclosing task body are not
+comparable in any meaningful way to those of the caller of the
+corresponding entry.
+
+The second issue is that we didn't cover all cases of where an access
+discriminant might be specified via an anonymous allocator. Essentially
+any place there is a subtype_indication involving a discriminated
+type, or an access-to-discriminated type, there is the possibility
+that an access discriminant might be constrained by an allocator.
+We have chosen to simplify 3.10.2(14.1..3) by reordering the 
+paragraphs, handling the interesting case first, namely when an
+allocator is used to define the discriminant of an object, and
+handling all the rest by saying that the level of the allocated
+object is the same as that of the master that elaborates the
+subtype_indication (or equivalently, that evaluates the allocator).
+
 --!corrigendum A.18.2(239/2)
 
 
@@ -2325,4 +2404,48 @@
 starting at anchor#2 and going up toward library level.
 
 ****************************************************************
+
+From: Tucker Taft
+Date: Friday, May 18, 2007  2:30 PM
+
+Here is an AI [This is version /02 of the AI] that
+attempts to fix a few holes in the
+accessibility level story.  Basically, we revert to
+talking about masters when we might be in a situation
+where we are comparing a level from an enclosing task
+body against a level coming in via a parameter to an
+accept statement.  These levels are fundamentally
+incomparable, since they can be associated with separate,
+unrelated task stacks.
+
+Also, we plug some holes relating to anonymous allocators
+used to define access discriminant constraints.
+
+Read it and weep ...
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, May 18, 2007  11:58 PM
+
+> Read it and weep ...
+
+Really.
+
+The second sentence of the AARM note 4.8(10.1/2) reads:
+"This can happen when an allocator initialized by a parameter passed
+in to an accept statement is performed using an access type declared
+in the enclosing task body."
+
+I used to think that AARM notes were supposed to *help* the reader.
+What the heck is "an allocator ... is performed using an access type..."?
+I don't think I've ever "performed" an allocator. :-) A longer/clearer
+explanation is needed. (A short example is probably going to be needed
+in the AARM for this; surely if you can't explain it better!)
+
+(The similar note in 6.5 seems to make sense, so it is just this one
+that is a mess.)
+
+****************************************************************
+