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

--- ai05s/ai05-0190-1.txt	2011/02/10 07:48:26	1.11
+++ ai05s/ai05-0190-1.txt	2011/02/16 06:15:23	1.12
@@ -46,8 +46,16 @@
     ultimate ancestor of the access type is declared;
   * For an allocator of an anonymous access parameter type, the master
     of the call that contains the allocator;
+  * For an allocator of an anonymous access result type
+    Redundant[used in a return statement],
+    the master of the return object;
+    AARM Discussion: The master of the return object changes during the
+    execution of a return statement; this refers to whatever master the object
+    has at the present time. Note that we don't need a similar rule for access
+    discriminants because these rules do not have to handle coextensions.
   * For an allocator of other kinds of anonymous access types, the
-    master in which the associated entity is declared.
+    master in which the entity associated with the anonymous access type
+    is declared.
     AARM Discussion: The associated entity will be a record type
     (discriminant or component) or object declaration.
 
@@ -3150,6 +3158,223 @@
 point), but it is not as clear to me that that is intended.
 
 Ideas welcome.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, February 10, 2011  1:56 PM
+
+> Replace 7.6.1(11/3) [as modified by AI05-0051-1] with:
+>
+> The *collection master* of an allocator of an access type is:
+>   * For an allocator of a named access type, the master in which the
+>     ultimate ancestor of the access type is declared;
+>   * For an allocator of an anonymous access parameter type, the master
+>     of the call that contains the allocator;
+>   * For an allocator of other kinds of anonymous access types, the
+>     master in which the associated entity is declared.
+>     AARM Discussion: The associated entity will be a record type
+>     (discriminant or component) or object declaration.
+>
+... or record subtype, as in
+
+     subtype S is Some_Type_With_An_Access_Discriminant
+       (Discrim => new Designated_Type);
+
+or an anonymous object (as for an aggregate or function result).
+
+What about all the anonymous function result type interactions with nested-scope
+extension types first discussed in AI05-0051?
+
+Perhaps you only want to define "collection master" and "collection point" for
+non-coextension allocators. The finalization point rules for coextensions don't
+need further specification in this AI and this might allow the definitions to be
+simpler (otherwise, it is not obvious (to me) that there are no interactions
+with the "ultimate master" stuff in AI05-0234).
+
+> The *collection point* of an allocator of an access type is:
+>   * For an allocator of a named access type, the freezing point of the
+>     ultimate ancestor of the access type is declared;
+
+Typo (I think): delete the two words "is declared" above?
+
+>   * For an allocator of an anonymous access parameter type, the
+>     call that contains the allocator;
+
+Is this a change? Compare the "innermost master that evaluates the aggregate or
+function_call" wording of 3.10.2(10/2). Consider a procedure call passes in two
+function calls, each of which passes in an access-parameter allocator:
+
+     P (F (new Designated), F (new Designated));
+
+Do the two calls to F define two different collection points?
+I would have thought that the call to P would be the one and only collection
+point in this example.
+
+>   * For an allocator of an anonymous access type declared as part of
+>     a stand-alone object declaration, the freezing point of the
+> object;
+
+>   * For an allocator of an anonymous access type that declares a component,
+>     the freezing point of the composite type that declares the component.
+>
+
+Do you need to say "that declares a non-discriminant component" above?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011  7:24 PM
+
+> > Replace 7.6.1(11/3) [as modified by AI05-0051-1] with:
+> >
+> > The *collection master* of an allocator of an access type is:
+> >   * For an allocator of a named access type, the master in which the
+> >     ultimate ancestor of the access type is declared;
+> >   * For an allocator of an anonymous access parameter type, the master
+> >     of the call that contains the allocator;
+> >   * For an allocator of other kinds of anonymous access types, the
+> >     master in which the associated entity is declared.
+> >     AARM Discussion: The associated entity will be a record type
+> >     (discriminant or component) or object declaration.
+> >
+> ... or record subtype, as in
+>
+>      subtype S is Some_Type_With_An_Access_Discriminant
+>        (Discrim => new Designated_Type);
+
+No, we're talking about the entity that declares the anonymous access type, not
+the allocator. That probably needs clarification.
+
+> What about all the anonymous function result type interactions with
+> nested-scope extension types first discussed in AI05-0051?
+
+You'll have to tell me. I have no clue.
+
+> Perhaps you only want to define "collection master" and "collection
+> point" for non-coextension allocators. The finalization point rules
+> for coextensions don't need further specification in this AI and this
+> might allow the definitions to be simpler (otherwise, it is not
+> obvious (to me) that there are no interactions with the "ultimate
+> master" stuff in AI05-0234).
+
+Neither of these definitions are used for any coextension cases, and I made no
+effort to care about coextensions cases beyond ensuring that there is some
+definition in that case. The wording that uses these definitions explicitly
+excludes all coextensions because 7.6.1(9.1/2) already covers that, and we don't
+want any hint of anything else conflicting with that.
+
+> > The *collection point* of an allocator of an access type is:
+> >   * For an allocator of a named access type, the freezing
+> point of the
+> >     ultimate ancestor of the access type is declared;
+>
+> Typo (I think): delete the two words "is declared" above?
+
+Right.
+
+> >   * For an allocator of an anonymous access parameter type, the
+> >     call that contains the allocator;
+>
+> Is this a change? Compare the "innermost master that evaluates the
+> aggregate or function_call" wording of 3.10.2(10/2). Consider a
+> procedure call passes in two function calls, each of which passes in
+> an access-parameter allocator:
+>
+>      P (F (new Designated), F (new Designated));
+>
+> Do the two calls to F define two different collection points?
+> I would have thought that the call to P would be the one and only
+> collection point in this example.
+
+They have the same master, and different collection points. This isn't a change,
+because this was defined completely wrong in the past (as the freezing point of
+the access type). 3.10.2 has nothing to do with it -- other than that this
+wording should be consistent. So I assume that compilers have done "something"
+here, but whatever it is has no support from the language wording.
+
+The only effect of having different collection points is to require an ordering.
+I don't see any way to avoid that, because the ordering within masters is
+(usually) important. For instance, if these allocators were used such that they
+were not directly in a master (consider aliased parameters, for instance), the
+order of finalization is very important.
+
+There might be some way to get the effect you want, but it would be very
+complex. (And we'd have to abandon this attempt at wording altogether; it cannot
+be done this way.)
+
+> >   * For an allocator of an anonymous access type declared as part of
+> >     a stand-alone object declaration, the freezing point of the
+> > object;
+>
+> >   * For an allocator of an anonymous access type that
+> declares a component,
+> >     the freezing point of the composite type that declares
+> the component.
+> >
+>
+> Do you need to say "that declares a non-discriminant component" above?
+
+Same as above: coextensions are irrelevant here, as this is never used for them.
+But I wanted it defined in some way for them, so we don't get into arguments
+about whether the order that rules are applied in are significant. I toyed with
+having a separate bullet for coextensions but that seemed like overkill when it
+will never be used.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011  1:10 AM
+
+> > >   * For an allocator of other kinds of anonymous access types, the
+> > >     master in which the associated entity is declared.
+> > >     AARM Discussion: The associated entity will be a record type
+> > >     (discriminant or component) or object declaration.
+...
+> No, we're talking about the entity that declares the anonymous access
+> type, not the allocator. That probably needs clarification.
+
+Actually, the wording is just wrong. I changed it to:
+
+  * For an allocator of other kinds of anonymous access types, the
+    master in which the entity associated with the anonymous access type
+    is declared.
+
+which is what Tucker suggested that we use.
+
+> > What about all the anonymous function result type interactions with
+> > nested-scope extension types first discussed in AI05-0051?
+
+I suspect that I need another bullet for that case. Since we don't care about
+coextensions here, we just have to deal with anonymous access function results.
+This bullet would go before the one noted above:
+
+   * For an allocator of an anonymous access result type Redundant[used in a
+     return statement], the master of the return object;
+     AARM Discussion: The master of the return object changes during the
+     execution of a return statement; this refers to whatever master the object
+     has at the present time. Note that we don't need a similar rule for access
+     discriminants because these rules do not have to handle coextensions.
+
+> The only effect of having different collection points is to require an
+> ordering. I don't see any way to avoid that, because the ordering within
+> masters is (usually) important. For instance, if these allocators were used
+> such that they were not directly in a master (consider aliased parameters, for
+> instance), the order of finalization is very important.
+
+This example isn't complete enough. Imagine a function call used in a renames,
+with an explicitly aliased parameter that is an aggregate with components that
+are anonymous allocators. In this case, the master of the aggregate (and thus
+the allocators) is that of the renames (which is fairly long-lived). The
+ordering within the "call tree" probably isn't significant (although the
+existing wording seems to make it so), but we don't want to allow this
+finalization to "float away" from the renames; it has to be done in order after
+the following declaration and before any preceding declaration.
+
+This is the ordering of finalization *within* a master; as I showed in previous
+examples, this is very important to have defined because otherwise a lot of
+legitimate finalization (especially at library level) has no hope of working
+consistently.
 
 ****************************************************************