CVS difference for ai12s/ai12-0258-1.txt

--- ai12s/ai12-0258-1.txt	2018/02/27 04:21:26	1.1
+++ ai12s/ai12-0258-1.txt	2018/03/07 00:22:25	1.2
@@ -1,5 +1,7 @@
-!standard A.18(10/4)                                     18-02-26  AI12-0258-1/01
+!standard A.18(10/4)                                     18-03-05  AI12-0258-1/02
 !class binding interpretation 18-02-26
+!status Amendment 1-2012 18-03-05
+!status ARG Approved 11-0-1  18-03-05
 !status work item 18-02-26
 !status received 18-01-28
 !priority Low
@@ -34,16 +36,18 @@
 
 Implementation Requirements
 
-For an indefinite container (one whose name includes "Indefinite"), each
-element of the container shall be created when it is inserted into the container
-and finalized when it is deleted (or when the container object is finalized
-if the element is not deleted). For a bounded container (one whose name starts
-with "Bounded") that is not indefinite, all of the
-elements of the capacity of the container shall be created and default
-initialized when the container object is created; the elements shall be
-finalized when the container object is finalized. 
-Redundant[For other kinds of containers, when objects are created and
-finalized is unspecified.]
+For an indefinite container (one whose type is defined in an instance of a
+child package of Containers whose defining_identifier contains "Indefinite"),
+each element of the container shall be created when it is inserted into the
+container and finalized when it is deleted from the container (or when the
+container object is finalized if the element has not been deleted). For a
+bounded container (one whose type is defined in an instance of a child
+package of Containers whose defining_identifier starts with "Bounded") that
+is not an indefinite container, all of the elements of the capacity of the
+container shall be created and default initialized when the container object
+is created; the elements shall be finalized when the container object is
+finalized. Redundant[For other kinds of containers, when elements are created
+and finalized is unspecified.]
 
 AARM Ramification: This allows a user to be able to reason about the behavior
 of elements that have controlled parts. In most cases, such elements need to
@@ -54,14 +58,28 @@
 and that a bounded container contains an array of elements or other data
 structure that is initialized for the entire capacity of the container when
 it is created. There is no such restriction on the implementation of the
-"normal" containers; these can be handled in any way convinient to the
+"normal" containers; these can be handled in any way convenient to the
 implementation -- in particular, node reuse is allowed.
 
+Replace AARM A.18(5.r/2) with:
+
+If a container's element type is controlled, the point at which the element is
+finalized will depend on the implementation of the container. For certain
+kinds of containers, we require finalization behavior based on the canonical
+implementation of the container (see the Implementation Requirements below).
+For the "normal" containers, we do not specify precisely where this will
+happen (it will happen no later than the finalization of the container, of
+course) in order to give implementations flexibility to cache, block, split,
+or reuse the nodes of the container.
+
+Delete AARM A.18(5.s/2).
+
 !discussion
 
 The original intent was that the semantics of controlled elements would follow
 from the underlying Ada implementation - thus, no guarantees were given in
 order to allow maximum flexibility for the implementation of the containers.
+(See the Language Design Principles in AARM A.18(5.r-5.t/2) for a discussion.)
 
 However, without some sort of guarantees, the containers are mostly useless
 for containing elements of controlled types.
@@ -74,16 +92,39 @@
 
 Therefore, we provide some rules on what is expected for controlled types
 when used in the containers. These suggest that a user who have controlled
-parts to their element types must use an indefinite container. (Users with
-memory management concerns can uses a Bounded_Indefinite_Holder [see
+parts in their element types must use an indefinite container. (Users with
+memory management concerns can use a Bounded_Indefinite_Holder [see
 AI12-0254-1] inside a bounded container to get the correct semantics).
 
+!corrigendum A.18(10/2)
+
+@dinsa
+@xbullet<finalization of the collection of the access type has started if and
+only if the finalization of the instance has started.>
+@dinst
+For an indefinite container (one whose type is defined in an instance of a
+child package of Containers whose @fa<defining_identifier> contains "Indefinite"),
+each element of the container shall be created when it is inserted into the
+container and finalized when it is deleted from the container (or when the
+container object is finalized if the element has not been deleted). For a
+bounded container (one whose type is defined in an instance of a child
+package of Containers whose @fa<defining_identifier> starts with "Bounded") that
+is not an indefinite container, all of the elements of the capacity of the
+container shall be created and default initialized when the container object
+is created; the elements shall be finalized when the container object is
+finalized. For other kinds of containers, when elements are created
+and finalized is unspecified.
+
 !ASIS
 
 No ASIS effect.
 
 !ACATS test
 
+ACATS C-Tests can be created to check this for Indefinite and Bounded
+containers (the other containers are unspecified). Probably check the
+holders (including the new one) and a couple of others - exhaustive tests
+would be exhausting :-), and wouldn't add a lot of value.
 
 !appendix