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.)
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent