CVS difference for ais/ai-00416.txt

Differences between 1.13 and version 1.14
Log of other versions for file ais/ai-00416.txt

--- ais/ai-00416.txt	2005/11/16 06:51:17	1.13
+++ ais/ai-00416.txt	2005/12/15 02:44:18	1.14
@@ -1,4 +1,4 @@
-!standard 3.2.3(01)                                     05-11-15  AI95-00416/12
+!standard 3.2.3(01)                                     05-11-30  AI95-00416/13
 !standard 3.3(10)
 !standard 3.7(27)
 !standard 3.9.2(02)
@@ -253,14 +253,12 @@
 
 Replace 3.10.2(10) with:
 
-    * The accessibility level of the result of a function call that is used to
+    * The accessibility level of an aggregate or the result of a function call
+      (or equivalent use of an operator) that is used (in its entirety) to
       directly initialize part of an object is that of the object being
-      initialized from the execution of the called function result. The
-      accessibility level of the result of a function call that is renamed in
-      whole or in part is that of the innermost master of the
-      object_renaming_declaration. Otherwise, the accessibility level of the
-      result of a function call is that of the innermost master of the function
-      call.
+      initialized. In other contexts, the accessibility level of an aggregate
+      or the result of a function call is that of the innermost master
+      that evaluated the aggregate or function call.
 
 Add after 3.10.2(10):
 
@@ -291,12 +289,13 @@
       allocator, or in the expression or return_subtype_indication of
       a return statement is determined as follows:
 
-       + For an access discriminant whose value is determined by a
+       + If the value of the access discriminant is determined by a
          discriminant_association in a subtype_indication, the
          accessibility level of the object or subprogram designated by
          the associated value (or library level if the value is null);
 
-         AARM NOTE: This deals with the following cases:
+         AARM NOTE: This deals with the following cases,
+            when they occur in the context of an allocator or return statement:
    	     - Extension aggregate where ancestor part is a subtype_mark
    	       denoting a constrained subtype;
    	     - Uninitialized allocator where subtype_indication defines
@@ -306,19 +305,29 @@
    	       a function with a constrained result subtype, the dereference
    	       of an access-to-constrained subtype, etc.
 
-       + For an access discriminant of an object defined by an aggregate
-         where the value of the discriminant is determined by a
-         component_association in the aggregate, the accessibility
+       + If the value of the access discriminant is determined by a
+         component_association in an aggregate, the accessibility
          level of the object or subprogram designated by the associated
          value (or library level if the value is null);
 
-       + For an access discriminant of any other object with an unconstrained
+         AARM NOTE: In this bullet, the aggregate has to occur in the
+         context of an allocator or return statement, while the
+         subtype_indication of the previous bullet can occur anywhere
+         (it doesn't have to be directly given in the allocator or
+         return statement).
+
+       + In other cases, where the value of the access discriminant
+         is determined by an object with an unconstrained
          nominal subtype, the accessibility level of the object.
 
       AARM NOTE: In other words, if you know the value of the discriminant
-        from a discriminant constraint or an aggregate component association,
-        then that determines the accessibility level; if you don't know it,
-        then it is based on the object itself.
+        for an allocator or return statement from a discriminant constraint or
+	an aggregate component association, then that determines the
+	accessibility level; if you don't know it, then it is based on the
+	object itself.
+
+   * The accessibility level of the anonymous access type of an access
+     discriminant in any other contect is that of the enclosing object.
 
 Delete 3.10.2(12.a/2) (it was moved up to be after paragraph 7/2).
 
@@ -492,8 +501,9 @@
      than a package_body; [the elaboration of a declaration other than
      the declaration of a package; ] the execution of [an accept_statement,
      a block_statement, or a simple_statement] {a statement}; or the
-     evaluation of an expression{, name,} or range that is not part of
-     an enclosing expression, {name,} range, or...
+     evaluation of an expression{, function_call,} or range that is not part of
+     an enclosing expression, {function_call,} range, or simple_statement
+     {other than a simple_return_statement}...
 
 Add after 7.6.1(9):
 
@@ -549,8 +559,21 @@
      Each such "whole" object has its own task activation sequence, involving
      the activating task being suspended until all the new tasks complete
      their activation.
+
+Drop the changes to paragraphs 9.3(2) and 9.3(3) added by AI-162. Add after
+9.3(3):
 
-Drop the changes to paragraphs 9.3(2) and 9.3(3) added by AI-162.
+   * Otherwise, the task depends on the
+     master of the outermost object of which it is a part (as
+     determined by the accessibility level of that object -- see
+     3.10.2 and 7.6.1), as well as on any master whose execution
+     includes that of the master of the outermost object.
+
+     AARM NOTE: The master of a task created by a return
+                statement changes when the accessibility of the return
+                object changes. Note that its activation happens, if at
+                all, only after the function returns and all
+                accessibility level changes have occurred.
 
 Change the first bullet added by the replacement of 13.11(25) in AI-230
 as follows:
@@ -855,13 +878,12 @@
 elaborated the function body. For any other function, the accessibility level
 of the result object is that of the execution of the called function.>
 @dby
-@xbullet<The accessibility level of the result of a function call that is used
+@xbullet<The accessibility level of an @fa<aggregate> or the result of a
+function call (or equivalent use of an operator) that is used (in its entirety)
 to directly initialize part of an object is that of the object being
-initialized from the execution of the called function result. The accessibility
-level of the result of a function call that is renamed in whole or in part is
-that of the innermost master of the @fa<object_renaming_declaration>.
-Otherwise, the accessibility level of the result of a function call is that of
-the innermost master of the function call.>
+initialized. In other contexts, the accessibility level of an @fa<aggregate> or
+the result of a function call is that of the innermost master that evaluated
+@fa<aggregate> or function call.>
 
 @xbullet<Within a return statement, the accessibility level of the return
 object is that of the execution of the return statement. If the
@@ -891,20 +913,23 @@
 @fa<allocator>, or in the @fa<expression> or @fa<return_subtype_indication> of
 a return statement is determined as follows:>
 
-@xinbull<For an access discriminant whose value is determined by a
+@xinbull<If the value of the access discriminant is determined by a
 @fa<discriminant_association> in a @fa<subtype_indication>, the
 accessibility level of the object or subprogram designated by
 the associated value (or library level if the value is null);>
 
-@xinbull<For an access discriminant of an object defined by an @fa<aggregate>
-where the value of the discriminant is determined by a
-@fa<component_association> in the @fa<aggregate>, the accessibility
+@xinbull<If the value of the access discriminant is determined by a
+@fa<component_association> in an @fa<aggregate>, the accessibility
 level of the object or subprogram designated by the associated
 value (or library level if the value is null);>
 
-@xinbull<For an access discriminant of any other object with an unconstrained
+@xinbull<In other cases, when the value of the access discriminant is
+determined an object with an unconstrained
 nominal subtype, the accessibility level of the object.>
 
+@xbullet<The accessibility level of the anonymous access type of an access
+discriminant in any other context is that of the enclosing object.>
+
 !corrigendum 3.10.2(13)
 !comment A fake to force a conflict.
 
@@ -1122,8 +1147,9 @@
 that is taking place. Leaving an execution happens immediately after its
 completion, except in the case of a @i<master>: the execution of a body other than
 a @fa<package_body>; the execution of a @fa<statement>; or
-the evaluation of an @fa<expression>, @fa<name>, or @fa<range> that is not part of an
-enclosing @fa<expression>, @fa<name>, @fa<range>, or @fa<simple_statement>.
+the evaluation of an @fa<expression>, @fa<function_call>, or @fa<range> that is not part of an
+enclosing @fa<expression>, @fa<function_call>, @fa<range>, or @fa<simple_statement>
+other than a @fa<simple_return_statement>.
 A master is finalized after it is complete, and before it is left.
 
 
@@ -1211,7 +1237,18 @@
 of an object that is the result of a function call, the activations are
 not initiated until after the function returns.
 
+!corrigendum 9.3(3)
 
+@dinsa
+@xbullet<If the task is created by the elaboration of an
+@fa<object_declaration>, it depends on each master that includes this
+elaboration.>
+@dinst
+@xbullet<Otherwise, the task depends on the master of the
+outermost object of which it is a part (as determined by the accessibililty
+level of that object @emdash see 3.10.2 and 7.6.1), as well as on any master
+whose execution includes that of the master of the outermost object.>
+
 !corrigendum 13.11(25)
 
 @drepl
@@ -1248,7 +1285,7 @@
 !corrigendum 13.11.2(9)
 
 @drepl
-@xhang<@xterm<3.>Free(X), when X is not equal to @b<null> first performs
+@xhang<@xterms<3.>Free(X), when X is not equal to @b<null> first performs
 finalization, as described in 7.6. It then deallocates the storage
 occupied by the object designated by X. If
 the storage pool is a user-defined object, then the storage is
@@ -1261,7 +1298,7 @@
 object being freed contains tasks, the object might not be
 deallocated.
 @dby
-@xhang<@xterm<3.>Free(X), when X is not equal to @b<null> first performs
+@xhang<@xterms<3.>Free(X), when X is not equal to @b<null> first performs
 finalization of the object designated by X (and any coextensions of the
 object @emdash see 3.10.2), as described in 7.6.1. It then deallocates the
 storage occupied by the object designated by X (and any coextensions). If
@@ -1459,6 +1496,349 @@
 the AI.
 
 So those who were concerned can breathe easier. ;-)
+
+*************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, November 30, 2005  4:22 AM
+
+Unless I missed something...
+
+9.3 (3) talks about task created by the elaboration of an object
+declaration. But the identifer of an extended return is not an object
+declaration. Moreover, we don't want the master to be the function; it
+should be the *caller* of the function (i.e. the place where the "return
+object" is created).
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, November 30, 2005  8:26 AM
+
+> Unless I missed something...
+
+You did. I hope. :-)
+
+> 9.3 (3) talks about task created by the elaboration of an object
+> declaration. But the identifer of an extended return is not an object
+> declaration. Moreover, we don't want the master to be the function; it
+> should be the *caller* of the function (i.e. the place where the "return
+> object" is created).
+
+The master is determined by the accessibility level in general (see 3.10.2).
+3.10.2(10.1) describes the accessibility level for return objects. The
+intent is clearly that this determines when finalization and task waiting
+occurs (see 6.5(5.e-5.f) for instance).
+
+In any case, for a limited type, the return object is really a view of the
+ultimate result. The tasks are created directly in this ultimate result.
+(This is required by 7.5(9.1)). The ultimate result has to be an allocator
+or an object_declaration (other uses of limited expressions are illegal), so
+I think the master is defined. (If the return object is never returned, the
+tasks are never activated, so they don't need to be waited for or even have
+a master.)
+
+Admittedly, this is a bit hand-wavey, but it seems like a lot of wording
+would need changes otherwise, and I'd rather avoid that at this late date.
+Perhaps we should add an AARM note somewhere, but what would it say??
+
+*************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, December  1, 2005  3:11 AM
+
+> The master is determined by the accessibility level in general (see 3.10.2).
+> 3.10.2(10.1) describes the accessibility level for return objects. The
+> intent is clearly that this determines when finalization and task waiting
+> occurs (see 6.5(5.e-5.f) for instance).
+>
+There is no doubt about the intent, but this justification is a bit
+far-reaching (we are talking about access types here)...
+
+You say that "The master *is determined* by the accessibility level",
+but the RM says "Each master, and each entity and view created by it,
+*has* an accessibility level". I don't think that the RM says that the
+master of an entity is the construct that corresponds to its
+accessibility level.
+
+The place that defines what is the master of a task is clearly 9.3. Why
+not add a third bullet after 9.3(3) that says the truth:
+
+    If the task is created by the elaboration of the return object of an
+    extended_return_statement, the master is the function to which the
+    extended_return_statement applies until the function returns; when
+    the function returns, the master is changed to be the master that
+    elaborated the declaration for which this function call is the
+    initialization expression.
+
+AARM note:
+    Other rules ensure that a function that returns a task can be used
+    only as the initialization expression of an object declaration.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, December  1, 2005  4:07 AM
+
+> You say that "The master *is determined* by the accessibility level",
+> but the RM says "Each master, and each entity and view created by it,
+> *has* an accessibility level". I don't think that the RM says
+> that the
+> master of an entity is the construct that corresponds to its
+> accessibility level.
+
+It does, in 7.6.1(13), this is the rule that ties masters to accessibility
+levels and makes it possible to define the dependence/finalization rules
+by "simply" specifying accessibility levels.
+
+> Why not add a third bullet after 9.3(3) that says the truth:
+>
+>     If the task is created by the elaboration of the return object of an
+>     extended_return_statement, the master is the function to which the
+>     extended_return_statement applies until the function returns; when
+>     the function returns, the master is changed to be the master that
+>     elaborated the declaration for which this function call is the
+>     initialization expression.
+
+This would be redundant with 3.10.2(10.1), and we certainly don't want to
+introduce redundancy in the accessibility rules, they are complicated
+enough as they stand.  Furthermore, the above doesn't work: it doesn't
+address simple_return_statements, finalization of controlled types,
+coextensions, and function calls that are being renamed.
+
+I agree that 9.3(2-3) are a bit bogus because there are other ways to
+create tasks than allocators and object_declarations, but if we absolutely
+wanted to fix them, the best option would be to delete them altogether and
+depend on the accessibility rules.
+
+But that seems insufficiently broken to me.  Maybe an AARM note saying
+"there are other ways to create tasks, go read 3.10.2" would help.
+
+*************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, December  1, 2005  3:11 AM
+
+> I agree that 9.3(2-3) are a bit bogus because there are other ways to
+> create tasks than allocators and object_declarations, but if we absolutely
+> wanted to fix them, the best option would be to delete them altogether and
+> depend on the accessibility rules.
+>
+> But that seems insufficiently broken to me.  Maybe an AARM note saying
+> "there are other ways to create tasks, go read 3.10.2" would help.
+
+And a "to be honnest": masters of a task are not really defined here,
+but in 7.6.1(13).
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 1, 2005  12:22 PM
+
+In looking at 9.2(2-3) and 9.3(2-3) together, it is a bit
+weird that 9.2 talks carefully about all kinds of task objects,
+but 9.3 blithely only talks about tasks created by allocators
+or object declarations.  It would seem fairly straightforward to
+adapt the wording of 9.2(2-3) for 9.3(2-3), so these two
+sections are consistent.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 1, 2005  2:53 PM
+
+If you're suggesting this as an exercise for the editor, thanks, but I'll
+pass. A quick look at 9.2(2-3) shows an incredibly messy bunch of lists and
+conditions. How that maps to 9.3(2-3) is not at all clear to me.
+
+For now, I'll add some AARM notes as suggested, and if someone wants to take
+a stab at fixing the wording and submitting it through one of the WG9
+channels, please go ahead.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 1, 2005  3:51 PM
+
+OK.  How does this sound?
+
+What exactly are the right channels for submission,
+by the way?
+
+-------------
+
+Existing 9.3(2-3):
+
+	* If the task is created by the evaluation of an allocator
+	for a given access type, it depends on each master that
+	includes the elaboration of the declaration of the ultimate
+	ancestor of the given access type.
+
+	* If the task is created by the elaboration of an
+	object_declaration, it depends on each master that includes
+	this elaboration.
+
+Add the following after the above:
+
+	* Otherwise, the master of the task is determined by the
+	master of the outermost object of which it is a part, as
+	determined by the accessibililty level of that object (see
+	3.10.2 and 7.6.1).
+
+		AARM NOTE: The master of a task created by a return
+		statement changes when the accessibility of the return
+		object changes. Note that its activation happens, if at
+		all, only after the function returns and all
+		accessibility level changes have occurred.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 1, 2005  4:16 PM
+
+> OK.  How does this sound?
+
+Looks OK to me, although it doesn't seem very similar to 9.2(2-3). (I don't
+care about that much anyway.)
+
+> What exactly are the right channels for submission, by the way?
+
+We're still working that out, but it would have to be via a
+head-of-delegation or liaison. In your case, either Joyce Tokar (US) or John
+McCormick (SIGAda).
+
+I'll try to make the rules clear when I post the next set of drafts. But I
+gotta finish them first...
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, December 1, 2005  4:55 PM
+
+> What exactly are the right channels for submission,
+> by the way?
+
+I want Randy to focus on draft 15 at this point, so that we can send it to
+WG9 for review, hopefully next week.
+
+To avoid confusion or arguments, draft 15 should exactly reflect what was
+decided at the last ARG meeting, not more, not less.  Otherwise we run the
+risk of indefinite postponement, and someone could well argue that we are
+bending the rules.
+
+As you know, once draft 15 has been sent to WG9, there will be a review
+period ending around January 31st.  Comments should be submitted to
+National Bodies or Liaison Organizations, who will forward them to AXE
+Consulting (aka Dr. Randy).  I think we want to be fairly formal in
+conducting this review, so there is no reason to have a special permission
+for the ARG members to submit comments directly.  Like the general public,
+they should go through NBs or LOs.  After all, it should not be too hard
+for ARG members to convince their favorite HoD to submit an official
+comment.
+
+*************************************************************
+
+From: Dan Eilers
+Sent: Friday, December 1, 2005 11:51 AM
+
+>                              I think we want to be fairly formal in
+> conducting this review, so there is no reason to have a special permission
+> for the ARG members to submit comments directly.
+
+This seems to be mistaken.  "We" as in "the Arg" aren't conducting this
+review--it's a WG9 review.  The WG9 minutes for meeting #48 say:
+
+#   T through T+30: Informal review by member bodies and "socialization"
+#    to the public, resulting in minor comments.
+
+So it appears that the intent of WG9 is for this to be an _informal_ review.
+And it appears that the intent is to receive comments both from member
+bodies and the public, with no mention that the public comments should go
+through the member bodies as opposed to the normal channels for public
+comments.
+
+> To avoid confusion or arguments, draft 15 should exactly reflect what was
+> decided at the last ARG meeting, not more, not less.  Otherwise we run the
+> risk of indefinite postponement, and someone could well argue that we are
+> bending the rules.
+
+The WG9 minutes for meeting #49 say:
+#   If the amendment completes its current review in the ARG without
+#   comments requiring substantial remark then it should be possible for
+#   the ARG to make an informational distribution in early December.
+
+Since this is only an "informational" distribution, there doesn't seem
+to be any reason to be overly concerned about "bending the rules",
+since there aren't really any rules for "informational" distributions.
+
+I am sympathetic to the concern about indefinite postponement, but the
+Rationale isn't available yet, and it will hardly be possible to conduct
+a meaningful review of the Amendment without the Rationale showing how
+the new features are intended to be be used, what AI's were discussed
+but not incorporated, and what incompatibilities were introduced.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Saturday, December 3, 2005  6:46 AM
+
+...
+> So it appears that the intent of WG9 is for this to be an
+> _informal_ review. And it appears that the intent is to
+> receive comments both from member bodies and the public, with
+> no mention that the public comments should go through the
+> member bodies as opposed to the normal channels for public comments.
+
+If you look at the draft minutes for meeting #49 you will find a sentence
+that says: 'The process is long past the stage when the ARG would accept
+comments from the "public"'.  The discussion at the meeting made it clear
+that WG9 wanted comments to be channeled through HoDs.  I expect this to
+be reflected in the final minutes.
+
+...
+> Since this is only an "informational" distribution, there
+> doesn't seem to be any reason to be overly concerned about
+> "bending the rules", since there aren't really any rules for
+> "informational" distributions.
+
+NBs and LOs may well have their own rules for conducting this kind of
+review, even though it's informal from the perspective of WG9.  I don't
+want to give anyone the impression that the ARG has somehow the privilege
+of short-circuiting these rules.  This may be overly cautious, but better
+safe than sorry.  The last thing I want at this stage is to ruffle
+feathers.
+
+> I am sympathetic to the concern about indefinite
+> postponement, but the Rationale isn't available yet, and it
+> will hardly be possible to conduct a meaningful review of the
+> Amendment without the Rationale showing how the new features
+> are intended to be be used, what AI's were discussed but not
+> incorporated, and what incompatibilities were introduced.
+
+Remember that the Rationale is not a deliverable of the ISO amendment
+process, and while I agree that it helps in understanding the new features
+of the language, I am sure that a "meaningful review" of the Amendment can
+be done (and has been done over the last year) without looking at the
+Rationale.  In particular, the Rationale is not at a level of detail
+sufficient to analyze the correctness of most of the individual rules.
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, December 4, 2005  9:34 AM
+
+> So it appears that the intent of WG9 is for this to be an _informal_
+> review.
+
+Putting on my WG9 HOD hat:
+The intent of the WG9 review is to informally solicit those comments from
+the country delegations that they would make if this draft version were
+officially submitted at this point. The intent is further that all such
+comments be made at this time and that no new issues be raised later about
+the officially submitted draft (and that this draft obviously addresses
+issues raised in the inofficial round). It is therefore important that all
+comments on the draft 15 be channeled through WG9. The only way to do so is
+via the heads of delegation.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent