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

--- ai12s/ai12-0035-1.txt	2013/06/10 22:16:13	1.4
+++ ai12s/ai12-0035-1.txt	2013/07/09 01:29:13	1.5
@@ -1,5 +1,16 @@
-!standard A.18(5/3)                                 13-06-10    AI12-0035-1/03
+!standard A.18(5/3)                                 13-07-08    AI12-0035-1/04
+!standard A.18.11(8/2)
+!standard A.18.12(7/2)
+!standard A.18.13(8/2)
+!standard A.18.14(8/2)
+!standard A.18.15(4/2)
+!standard A.18.16(4/2)
+!standard A.18.17(7/3)
+!standard A.18.18(39/3)
+!standard A.18.18(47/3)
 !class binding interpretation 12-06-08
+!status Amendment 202x 13-07-08
+!status ARG Approved 9-0-0  13-06-14
 !status work item 12-06-08
 !status received 12-06-07
 !priority Medium
@@ -10,7 +21,8 @@
 Certain operations of instances of the indefinite container packages
 require accessibility checks to prevent dangling references. This is
 specified in terms of the checks that would be required for executing
-an initialized allocator for an access type associated with the instance.
+an initialized allocator for a notional access type with the designated
+type of the element type of the instance.
 
 !question
 
@@ -37,24 +49,24 @@
 Add after A.18(5/3):
 
 Certain subprograms declared within instances of some of the generic packages
-presented in this clause are said to *perform indefinite allocation*. These
+presented in this clause are said to *perform indefinite insertion*. These
 subprograms are those corresponding (in the sense of the copying described
-in section 12.3) to subprograms that have formal parameters of a generic
+in subclause 12.3) to subprograms that have formal parameters of a generic
 formal indefinite type and that are identified as performing indefinite
-allocation in the subclause defining the generic package.
+insertion in the subclause defining the generic package.
 
-If a subprogram performs indefinite allocation, then certain run-time checks
+If a subprogram performs indefinite insertion, then certain run-time checks
 are performed as part of a call to the subprogram; if any of these checks
-fail, then the resulting exception is propagated to the caller and no container
-is modified by the call. These checks are performed for each parameter
+fail, then the resulting exception is propagated to the caller and the container
+is not modified by the call. These checks are performed for each parameter
 corresponding (in the sense of the copying described in 12.3) to a parameter
 in the corresponding generic whose type is a generic formal indefinite type.
 The checks performed for a given parameter are those checks explicitly
-specified in section 4.8 that would be performed as part of the evaluation
+specified in subclause 4.8 that would be performed as part of the evaluation
 of an initialized allocator whose access type is declared immediately within
 the instance, where:
 
-   - the initial value is the value of the parameter; and
+   - the value of the qualified_expression is that of the parameter; and
 
    - the designated subtype of the access type is the subtype of the
      parameter; and
@@ -62,106 +74,94 @@
    - finalization of the collection of the access type has started if and
      only if the finalization of the instance has started.
 
-AARM note:
-   The phrase "explicitly specified" means those checks for which section 4.8
+AARM Discussion:
+   The phrase "explicitly specified" means those checks for which subclause 4.8
    includes the phrase "<some exception> is raised if ...". It does not refer,
    for example, to any checks performed as part of any subtype conversion.
-   In particular, this wording includes the checks described in section 4.8
+   In particular, this wording includes the checks described in subclause 4.8
    to be performed in the case of a class-wide designated type, and of a
    designated subtype that has access discriminant parts. These checks are
    needed to prevent containers from outliving their contained (Element_Type
    or Key_Type) values.
 
-Discussion:
-   We are doing two things here. We are *requiring* checks needed to
+AARM Implementation note:
+   These rules have a dual purpose. Mainly, we are *requiring* checks needed to
    prevent dangling references. As a side effect, we are also *allowing*
    checks needed to permit an implementation of a container generic to
-   make use of access types in a straightforward way. Following that second
-   path, suppose that an implementation does declare such an access type and
-   suppose further that the access type's collection's finalization has
-   started. We want to allow Program_Error to be propagated in this case
-   (as specified in 4.8(10.2/2,11.1/2)).
+   make use of access types in a straightforward way. As an example of 
+   the second purpose, suppose that an implementation does declare such an
+   access type and suppose further that the access type's collection's
+   finalization has started. These rules allow Program_Error to be
+   propagated in this case (as specified in 4.8); this is necessary to
+   allow an all-Ada implementation of these packages.
 
 
-At the end of A.18.11 (Containers.Indefinite_Vectors), add:
+Add after A.18.11(8/2) (Containers.Indefinite_Vectors):
 
-Dynamic Semantics
+* The operations "&", Append, Insert, Prepend, Replace_Element, and To_Vector
+  that have a formal parameter of type Element_Type perform indefinite insertion
+  (see A.18).
 
-The operations "&", Append, Insert, Prepend, Replace_Element, and To_Vector
-that have a formal parameter of type Element_Type perform indefinite allocation
-(see A.18).
 
+Add after A.18.12(7/2) (Containers.Indefinite_Doubly_Linked_Lists):
 
-At the end of A.18.12 (Containers.Indefinite_Doubly_Linked_Lists), add:
+* The operations Append, Insert, Prepend, and Replace_Element that have a formal
+  parameter of type Element_Type perform indefinite insertion (see A.18).
 
-Dynamic Semantics
 
-The operations Append, Insert, Prepend, and Replace_Element that have a formal
-parameter of type Element_Type perform indefinite allocation (see A.18).
+Add after A.18.13(8/2) (Containers.Indefinite_Hashed_Maps):
 
+* The operations Include, Insert, Replace, and Replace_Element that have a formal
+  parameter of type Element_Type perform indefinite insertion (see A.18).
 
-At the end of A.18.13 (Containers.Indefinite_Hashed_Maps), add:
-
-Dynamic Semantics
-
-The operations Include, Insert, Replace, and Replace_Element that have a formal
-parameter of type Element_Type perform indefinite allocation (see A.18).
-
-AARM note: Some of the named operations also have a formal of the indefinite
-formal type Key_Type and perform indefinite allocation using that value, but
+AARM Discussion: Some of the named operations also have a formal of the indefinite
+formal type Key_Type and perform indefinite insertion using that value, but
 it's sufficient to mention the formal of type Element_Type.
-
 
-At the end of A.18.14 (Containers.Indefinite_Ordered_Maps), add:
+Add after A.18.14(8/2) (Containers.Indefinite_Ordered_Maps):
 
-Dynamic Semantics
+* The operations Include, Insert, Replace, and Replace_Element that have a formal
+  parameter of type Element_Type perform indefinite insertion (see A.18).
 
-The operations Include, Insert, Replace, and Replace_Element that have a formal
-parameter of type Element_Type perform indefinite allocation (see A.18).
-
-AARM note: Some of the named operations also have a formal of the indefinite
-formal type Key_Type and perform indefinite allocation using that value, but
+AARM Discussion: Some of the named operations also have a formal of the indefinite
+formal type Key_Type and perform indefinite insertion using that value, but
 it's sufficient to mention the formal of type Element_Type.
-
-
-At the end of A.18.15 (Containers.Indefinite_Hashed_Sets), add:
-
-Dynamic Semantics
 
-The operations Include, Insert, Replace, Replace_Element, and To_Set that have a
-formal parameter of type Element_Type perform indefinite allocation (see A.18).
+Add after A.18.15(4/2) (Containers.Indefinite_Hashed_Sets):
 
-AARM note: This also applies to the procedure Replace declared in the nested
-generic package Generic_Keys.
+* The operations Include, Insert, Replace, Replace_Element, and To_Set that have a
+  formal parameter of type Element_Type perform indefinite insertion (see A.18).
 
+AARM Ramification: This includes the procedure Replace declared in the nested
+generic package Generic_Keys, as well as the routines declared directly in the
+Containers.Indefinite_Hashed_Sets package.
 
-At the end of A.18.16 (Containers.Indefinite_Ordered_Sets), add:
+Add after A.18.16(4/2) (Containers.Indefinite_Ordered_Sets):
 
-Dynamic Semantics
+* The operations Include, Insert, Replace, Replace_Element, and To_Set that have a
+  formal parameter of type Element_Type perform indefinite insertion (see A.18).
 
-The operations Include, Insert, Replace, Replace_Element, and To_Set that have a
-formal parameter of type Element_Type perform indefinite allocation (see A.18).
+AARM Ramification: This includes the procedure Replace declared in the nested
+generic package Generic_Keys, as well as the routines declared directly in the
+Containers.Indefinite_Ordered_Sets package.
 
-AARM note: This also applies to the procedure Replace declared in the nested
-generic package Generic_Keys.
+Add after A.18.17(7/3) (Containers.Indefinite_Multiway_Trees):
 
+* The operations Append_Child, Insert_Child, Prepend_Child, and Replace_Element
+  that have a formal parameter of type Element_Type perform indefinite insertion
+  (see A.18).
 
-At the end of A.18.17 (Containers.Indefinite_Multiway_Trees), add:
+Modify A.18.18(39/3) (Containers.Indefinite_Holders):
 
-Dynamic Semantics
+Returns a nonempty holder containing an element initialized to New_Item.
+{To_Holder performs indefinite insertion (see A.18).}
 
-The operations Append_Child, Insert_Child, Prepend_Child, and Replace_Element
-that have a formal parameter of type Element_Type perform indefinite allocation
-(see A.18).
+Modify A.18.18(47/3) (Containers.Indefinite_Holders):
 
+Replace_Element assigns the value New_Item into Container, replacing any preexisting
+content of Container{; Replace_Element performs indefinite insertion (see A.18)}.
+Container is not empty after a successful call to Replace_Element.
 
-At the end of A.18.18 (Containers.Indefinite_Holders), add:
-
-Dynamic Semantics
-
-The operations Replace_Element and To_Holder that have a formal parameter of
-type Element_Type perform indefinite allocation (see A.18).
-
 !discussion
 
 Randy wrote the following as background for this AI:
@@ -226,7 +226,7 @@
 Those are the cases where dangling references could potentially be created,
 and are precisely the cases where an implementation that uses access types
 and allocators would naturally apply the accessibility checks required for
-allocators in section 4.8.
+allocators in subclause 4.8.
 
 Unfortunately there doesn't seem to be a simple way to characterize the set of
 operations (for example, it's a different set in each indefinite container),
@@ -292,7 +292,7 @@
       end Print_Obj;
 
    begin
-      Factory.Replace_Element (A);  -- This call should presumably fail
+      Factory.Replace_Element (A);  -- Raises Program_Error because of new rules
    end Set_Factory;
 
 begin
@@ -329,7 +329,7 @@
    begin
       Nested_Obj.C := 456;
 
-      Factory.Replace_Element (Nested_Obj); -- This call should presumably fail
+      Factory.Replace_Element (Nested_Obj); -- Raises Program_Error because of new rules
    end Set_Factory;
 
    procedure Print_Obj (Obj : Acc_Discrim_Rec) is
@@ -354,9 +354,146 @@
 
 end Dangling_Acc_Discrim;
 
+!corrigendum A.18(5/3)
+
+@dinsa
+When a formal function is used to provide an ordering for a container,
+it is generally required to define a strict weak ordering. A function "<"
+defines a @i<strict weak ordering> if it is irreflexive,
+asymmetric, transitive, and in addition, if @i<x> < @i<y> for
+any values @i<x> and @i<y>, then for all other values @i<z>,
+(@i<x> < @i<z>) or (@i<z> < @i<y>).
+@dinss
+@s8<@i<Static Semantics>>
+
+Certain subprograms declared within instances of some of the generic packages
+presented in this clause are said to @i<perform indefinite insertion>. These
+subprograms are those corresponding (in the sense of the copying described
+in subclause 12.3) to subprograms that have formal parameters of a generic
+formal indefinite type and that are identified as performing indefinite
+insertion in the subclause defining the generic package.
+
+If a subprogram performs indefinite insertion, then certain run-time checks
+are performed as part of a call to the subprogram; if any of these checks
+fail, then the resulting exception is propagated to the caller and the container
+is not modified by the call. These checks are performed for each parameter
+corresponding (in the sense of the copying described in 12.3) to a parameter
+in the corresponding generic whose type is a generic formal indefinite type.
+The checks performed for a given parameter are those checks explicitly
+specified in subclause 4.8 that would be performed as part of the evaluation
+of an initialized allocator whose access type is declared immediately within
+the instance, where:
+
+@xbullet<the value of the @fa<qualified_expression> is that of the parameter; and>
+
+@xbullet<the designated subtype of the access type is the subtype of the
+parameter; and>
+
+@xbullet<finalization of the collection of the access type has started if and
+only if the finalization of the instance has started.>
+
+
+!corrigendum A.18.11(8/2)
+
+@dinsa
+@xbullet<The actual Element parameter of access subprogram Process of
+Update_Element may be constrained even if Element_Type is unconstrained.>
+@dinst
+@xbullet<The operations "&", Append, Insert, Prepend, Replace_Element, and
+To_Vector that have a formal parameter of type Element_Type perform
+indefinite insertion (see A.18).>
+
+!corrigendum A.18.12(7/2)
+
+@dinsa
+@xbullet<The actual Element parameter of access subprogram Process of
+Update_Element may be constrained even if Element_Type is unconstrained.>
+@dinst
+@xbullet<The operations Append, Insert, Prepend, and Replace_Element that
+have a formal parameter of type Element_Type perform indefinite insertion
+(see A.18).>
+
+!corrigendum A.18.13(8/2)
+
+@dinsa
+@xbullet<The actual Element parameter of access subprogram Process of
+Update_Element may be constrained even if Element_Type is unconstrained.>
+@dinst
+@xbullet<The operations Include, Insert, Replace, and Replace_Element that
+have a formal parameter of type Element_Type perform indefinite insertion
+(see A.18).>
+
+!corrigendum A.18.14(8/2)
+
+@dinsa
+@xbullet<The actual Element parameter of access subprogram Process of
+Update_Element may be constrained even if Element_Type is unconstrained.>
+@dinst
+@xbullet<The operations Include, Insert, Replace, and Replace_Element that
+have a formal parameter of type Element_Type perform indefinite insertion
+(see A.18).>
+
+!corrigendum A.18.15(4/2)
+
+@dinsa
+@xbullet<The actual Element parameter of access subprogram Process of
+Update_Element_Preserving_Key may be constrained even if Element_Type
+is unconstrained.>
+@dinst
+@xbullet<The operations Include, Insert, Replace, Replace_Element, and
+To_Set that have a formal parameter of type Element_Type perform
+indefinite insertion (see A.18).>
+
+!corrigendum A.18.16(4/2)
+
+@dinsa
+@xbullet<The actual Element parameter of access subprogram Process of
+Update_Element_Preserving_Key may be constrained even if Element_Type
+is unconstrained.>
+@dinst
+@xbullet<The operations Include, Insert, Replace, Replace_Element, and
+To_Set that have a formal parameter of type Element_Type perform
+indefinite insertion (see A.18).>
+
+!corrigendum A.18.17(7/3)
+
+@dinsa
+@xbullet<The actual Element parameter of access subprogram Process of
+Update_Element may be constrained even if Element_Type is unconstrained.>
+@dinst
+@xbullet<The operations Append_Child, Insert_Child, Prepend_Child, and
+Replace_Element that have a formal parameter of type Element_Type perform
+indefinite insertion (see A.18).>
+
+!corrigendum A.18.18(39/3)
+
+@drepl
+@xindent<Returns a nonempty holder containing an element initialized to New_Item.>
+@dby
+@xindent<Returns a nonempty holder containing an element initialized to New_Item.
+To_Holder performs indefinite insertion (see A.18).>
+
+!corrigendum A.18.18(47/3)
+
+@drepl
+@xindent<Replace_Element assigns the value New_Item into Container, replacing
+any preexisting content of Container. Container is not empty after a successful
+call to Replace_Element.>
+@dby
+@xindent<Replace_Element assigns the value New_Item into Container, replacing
+any preexisting content of Container; Replace_Element performs indefinite
+insertion (see A.18). Container is not empty after a successful call to
+Replace_Element.>
+
+!ASIS
+
+No ASIS effect.
+
 !ACATS test
 
-** TBD.
+ACATS C-Tests should be constructed to check that the required checks are made
+(particularly in cases like the examples -- where the inserted object would
+have been dangling if the check is not made).
 
 !appendix