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

--- ai05s/ai05-0190-1.txt	2011/02/10 06:52:48	1.10
+++ ai05s/ai05-0190-1.txt	2011/02/10 07:48:26	1.11
@@ -1,4 +1,6 @@
-!standard 13.11.3(0)                                11-02-09  AI05-0190-1/07
+!standard 13.11.3(0)                                11-02-10  AI05-0190-1/08
+!standard 7.6.1(11/3)
+!standard H.4(8.1/3)
 !class amendment 09-11-03
 !status work item 09-11-03
 !status received 09-11-03
@@ -37,6 +39,51 @@
 
 !wording
 
+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.
+
+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;
+  * For an allocator of an anonymous access parameter type, the
+    call that contains the allocator;
+  * 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.
+
+The order in which the finalization of a master performs finalization of
+objects is as follows: Objects created by declarations in the master are
+finalized in the reverse order of their creation. For objects that were created
+by allocators whose collection master is this master and that are not coextensions
+of some other object, this rule is applied as though each such object that still
+exists had been created in an arbitrary order at the collection point of the
+allocator; the finalization of these objects is called the *finalization of the
+collection*. After the finalization of a master is complete, the objects
+finalized as part of its finalization cease to exist, as do any types and
+subtypes defined and created within the master.
+
+AARM Ramification: If multiple anonymous access types have the same collection
+point, the associated objects can be finalized in any order at that point.
+
+[Editor's note: This seems a lot more mess. I had to define two terms in
+order to avoid repeating the middle wording over and over and over. Moreover,
+we want to allow all of the "finalizations of the collections" of access types
+frozen at the same point to be finalized at the same time; we can't enforce any
+order (if multiple entities are frozen at the same point), so we ought not
+make any requirements at all. One possible simplification would be to split
+out the anonymous access parameter cases, since those are the most unusual of
+the bunch. But that doesn't seem to help much.]
+
 Renumber section 13.11.3, "Pragma Controlled" to be 13.11.4.
 Add a new section:
 
@@ -185,6 +232,23 @@
       but you can override it with a Storage_Pool or Storage_Size clause,
       or with another Default_Storage_Pool.
 
+The wording change to 7.6.1(11/3) is necessary as the AI05-0051-1 wording assumed
+that anonymous access types could not use a user storage pool. Since that's no
+longer true, the laissez faire finalization cannot work. As a practical matter,
+it never could have worked (it is all to easy to write code with such dependencies,
+see the mail of January 27, 2011 in the !appendix for some examples).
+
+In addition, the rules (both the Ada 2005 and the AI05-0051-1 version) does not
+properly handle allocators of anonymous access parameter types -- these belong
+to the master enclosing of the call, not the type declaration, and thus should be
+finalized there as well.
+
+Thus the only part of the AI05-0051-1 changes that we retain is the exception
+for coextensions (their finalization is defined by 7.6.1(9.1/2), not 7.6.1(11/3)).
+Otherwise, we define precisely where allocators of each kind of
+anonymous access type are finalized. We prefer to use the freezing point of the
+associated entity if in doubt.
+
 !example
 
     with My_Pools;
@@ -1536,7 +1600,8 @@
 > weak, and mainly seems to be an attempt to prevent ACATS test authors
 > from dreaming up tests of the finalization order of allocated
 > anonymous access types. It's hard to imagine a well-designed program
-> that would care; but if one exists, this laisse faire finalization probably wouldn't work right anyway.
+> that would care; but if one exists, this laisse faire finalization probably
+> wouldn't work right anyway.
 >
 > Thoughts??
 
@@ -2988,6 +3053,103 @@
 deallocate from). For a general access type, it still would be madness, but the
 sort of madness that is somehow expected for general access types. :-) But you
 still couldn't figure out deallocations.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011  1:46 AM
+
+I've made an attempt at this rewording, but I'm not terribly happy with the
+results.
+
+A reminder (from the !discussion of the AI):
+
+The wording change to 7.6.1(11/3) is necessary as the AI05-0051-1 wording
+assumed that anonymous access types could not use a user storage pool. Since
+that's no longer true, the laissez faire finalization cannot work. As a
+practical matter, it never could have worked (it is all to easy to write code
+with such dependencies, see the mail of January 27, 2011 in the !appendix for
+some examples).
+
+In addition, the rules (both the Ada 2005 and the AI05-0051-1 version) does not
+properly handle allocators of anonymous access parameter types -- these belong
+to the master enclosing of the call, not the type declaration, and thus should
+be finalized there as well.
+
+Thus the only part of the AI05-0051-1 changes that we retain is the exception
+for coextensions (their finalization is defined by 7.6.1(9.1/2), not
+7.6.1(11/3)). Otherwise, we define precisely where allocators of each kind of
+anonymous access type are finalized. We prefer to use the freezing point of the
+associated entity if in doubt.
+
+=====
+
+Following is the wording I came up with:
+
+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.
+
+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;
+  * For an allocator of an anonymous access parameter type, the
+    call that contains the allocator;
+  * 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.
+
+The order in which the finalization of a master performs finalization of objects
+is as follows: Objects created by declarations in the master are finalized in
+the reverse order of their creation. For objects that were created by allocators
+whose collection master is this master and that are not coextensions of some
+other object, this rule is applied as though each such object that still exists
+had been created in an arbitrary order at the collection point of the allocator;
+the finalization of these objects is called the *finalization of the
+collection*. After the finalization of a master is complete, the objects
+finalized as part of its finalization cease to exist, as do any types and
+subtypes defined and created within the master.
+
+AARM Ramification: If multiple anonymous access types have the same collection
+point, the associated objects can be finalized in any order at that point.
+
+====
+
+This is not some of my best work!
+
+I had to define two terms in order to avoid repeating the middle wording over
+and over and over. Moreover, we want to allow all of the "finalizations of the
+collections" of {anonymous only??) access types frozen at the same point to be
+finalized at the same time; we can't enforce any order (if multiple entities are
+frozen at the same point, there is no order to refer to), so we ought not make
+any requirements at all.
+
+Part of the trouble is the need to define what master these allocators belong
+to, and also the need to define *where* in that master they are finalized.
+Perhaps there is some way to combine these, but it escapes me at the moment.
+
+One possible simplification would be to split out the anonymous access parameter
+cases, since those are the most unusual of the bunch. But that doesn't seem to
+help much.
+
+I also point out that this wording allows objects of multiple named access types
+frozen at the same point to be interleaved. (That is, finalization is not of all
+of the objects of one access type, then all of the objects of another access
+type -- although it is typically implemented that way). I would argue that the
+Ada 2005 wording already allows this behavior (it talks about objects being
+finalized in an arbitrary order, without any restrictions beyond the freezing
+point), but it is not as clear to me that that is intended.
+
+Ideas welcome.
 
 ****************************************************************