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

Differences between 1.12 and version 1.13
Log of other versions for file ai05s/ai05-0190-1.txt

--- ai05s/ai05-0190-1.txt	2011/02/16 06:15:23	1.12
+++ ai05s/ai05-0190-1.txt	2011/03/05 06:51:41	1.13
@@ -1,4 +1,4 @@
-!standard 13.11.3(0)                                11-02-10  AI05-0190-1/08
+!standard 13.11.3(0)                                11-02-10  AI05-0190-1/09
 !standard 7.6.1(11/3)
 !standard H.4(8.1/3)
 !class amendment 09-11-03
@@ -41,57 +41,36 @@
 
 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 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 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.
+The finalization of a master performs finalization of objects created by
+declarations in the master in the reverse order of their creation.
+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.
+
+Each nonderived access type has an associated "collection", which is the set of objects
+created by allocators of the type, or of types derived from the type.
+Unchecked_Deallocation removes the object from its collection.
+(A coextension of an object X is an element of the same collection as X, if any.)
+Finalization of a collection consists of finalization of each object in the collection,
+in an arbitrary order. The collection of an access type is an object implicitly declared
+at the following place:
+
+    - For a named access type, the first freezing point (see 13.14) of
+      the type.
+
+    - For the type of an access parameter, the call that contains the
+      allocator.
+
+    - For any other anonymous access type, the first freezing point of
+      the innermost enclosing declaration.
+
+AARM Note: The place of the implicit declaration determines when allocated objects are
+finalized. For multiple collections declared at the same place, we do not define the
+order of their implicit declarations.
 
-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.
+Remove the AARM notes 3.3.2(38.i), 3.10(26.b), 13.11(43.b) as they talk about the
+Ada 83 definition of "collection" -- which would be just confusing now.
 
-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:
 
@@ -206,8 +185,8 @@
 
 NOTE
 Default_Storage_Pool may be used with restrictions No_Coextensions and
-No_Access_Parameter_Allocators (see H.4) to ensure that anonymous allocators
-are not an exception.
+No_Access_Parameter_Allocators (see H.4) to ensure that all allocators use the
+default pool.
 
 
 [End new section 13.11.3]
@@ -215,12 +194,12 @@
 Add new restrictions after H.4(8.1/3), i.e. immediately after
 No_Anonymous_Allocators:
 
-              No_Coextensions
-              There are no coextensions. See 3.10.2.
+         No_Coextensions
+         There are no coextensions. See 3.10.2.
 
-              No_Access_Parameter_Allocators
-              No allocator that is passed as the actual parameter to an
-              access parameter. See 6.1.
+         No_Access_Parameter_Allocators
+         Allocators are not permitted as the actual parameter to
+         an access parameter. See 6.1.
 
 !discussion
 
@@ -1809,9 +1788,9 @@
 
 > The original Storage_Size = 0 wording worked for generic bodies; it is
 > simply not checked there. See 4.8(5.3/2). However, we *deleted* that
-> rule in
-> AI05-0157-1 since it could not possibly ever happen (see AARM
-> 4.8(5.e/3)), and it eliminated checks on cases where we statically know the right answer.
+> rule in AI05-0157-1 since it could not possibly ever happen (see AARM
+> 4.8(5.e/3)), and it eliminated checks on cases where we statically know the
+> right answer.
 >
 > That happened because of issues with the Unchecked_Deallocation rule
 > that we were adding. So we will have to go back and redo that AI
@@ -2121,7 +2100,9 @@
 >        pragma Restrictions (No_Coextensions);
 >        pragma Restrictions (No_Access_Parameter_Allocators);
 
-If that makes you happy, it's fine with me.  I have no problem adding all manner of restrictions, and letter each project choose what restrictions to impose on itself.
+If that makes you happy, it's fine with me.  I have no problem adding all manner
+of restrictions, and letter each project choose what restrictions to impose on
+itself.
 
 Anyway, we've got to choose how to deal with this controversy, and it's really
 not all that important which way we choose. And concensus doesn't require
@@ -3378,3 +3359,85 @@
 
 ****************************************************************
 
+From: Bob Duff
+Sent: Saturday, February 19, 2011  9:27 AM
+
+Wording for AI05-0190-1, as requested during the ARG meeting yesterday.
+The intent is to clarify finalization points of objects created by allocators of
+anonymous access types.  The bulk of the AI remains unchanged.
+
+I re-reify the concept of "collection" from Ada 83.
+The collection is an object, so it's finalization point follows from where this
+object is implicitly declared.
+
+We no longer need to define the phrase "finalization of the collection", because
+it follows from the normal rules of English that it means, well, finalization of
+the collection.
+
+Replace 7.6.1(11/3) [as modified by AI05-0051-1] with:
+
+The finalization of a master performs finalization of objects created by
+declarations in the master in the reverse order of their creation.
+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.
+
+Each nonderived access type has an associated "collection", which is the set of objects
+created by allocators of the type, or of types derived from the type.
+Unchecked_Deallocation removes the object from its collection.
+(A coextension of an object X is an element of the same collection as X, if any.)
+Finalization of a collection consists of finalization of each object in the collection,
+in an arbitrary order. The collection of an access type is an object implicitly declared
+at the following place:
+
+    - For a named access type, the first freezing point (see 13.14) of
+      the type.
+
+    - For the type of an access parameter, the call that contains the
+      allocator.
+
+    - For any other anonymous access type, the first freezing point of
+      the innermost enclosing declaration.
+
+AARM Note: The place of the implicit declaration determines when allocated objects are
+finalized. For multiple collections declared at the same place, we do not define the
+order of their implicit declarations.
+
+[I think Tucker would like to loosen the above, to allow later finalization (which means
+an earlier implicit declaration of the collection). The above is the latest place where
+the collection can be implicitly declared. We could give permission to declare it earlier,
+but no earlier than the storage pool of the access type. I think Randy's issue was that
+the finalization of a heap object could happen after the pool, which is what this wording
+is trying to prevent.]
+
+The following AARM annotations need to be removed.
+In retrospect, these were pretty unhelpful anyway.
+
+3.3.2:
+
+38.i      As explained in Section 13, the concept of "storage pool" replaces
+          the Ada 83 concept of "collection." These concepts are similar, but
+          not the same.
+
+3.10:
+
+26.b      We use the term "storage pool" to talk about the data area from
+          which allocation takes place. The term "collection" is no longer
+          used. ("Collection" and "storage pool" are not the same thing
+          because multiple unrelated access types can share the same storage
+          pool; see 13.11 for more discussion.)
+
+13.11:
+
+43.b      Ada 83 had a concept called a "collection," which is similar to what
+          we call a storage pool. All access types in the same derivation
+          class shared the same collection. In Ada 95, all access types in the
+          same derivation class share the same storage pool, but other
+          (unrelated) access types can also share the same storage pool,
+          either by default, or as specified by the user. A collection was an
+          amorphous collection of objects; a storage pool is a more concrete
+          concept - hence the different name.
+
+[End list of removed AARM annotations.]
+
+****************************************************************

Questions? Ask the ACAA Technical Agent