CVS difference for ai12s/ai12-0035-1.txt
--- ai12s/ai12-0035-1.txt 2012/12/04 03:54:11 1.3
+++ ai12s/ai12-0035-1.txt 2013/06/10 22:16:13 1.4
@@ -1,4 +1,4 @@
-!standard A.18.18(47/3) 12-12-02 AI12-0035-1/02
+!standard A.18(5/3) 13-06-10 AI12-0035-1/03
!class binding interpretation 12-06-08
!status work item 12-06-08
!status received 12-06-07
@@ -7,10 +7,10 @@
!subject Accessibility checks for indefinite elements of containers
!summary
-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.
+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.
!question
@@ -34,73 +34,25 @@
!wording
-Add at the end of A.18:
+Add after A.18(5/3):
Certain subprograms declared within instances of some of the generic packages
-presented in this clause are said to "require indefinite allocation". These
-subprograms are those corresponding (in the sense of the copying described in
-section 12.3) to the following subprograms that have formal parameters of a
-generic formal indefinite type:
-
- Containers.Indefinite_Doubly_Linked_Lists.Append
- Containers.Indefinite_Doubly_Linked_Lists.Insert
- Containers.Indefinite_Doubly_Linked_Lists.Prepend
- Containers.Indefinite_Doubly_Linked_Lists.Replace_Element
-
- Containers.Indefinite_Hashed_Maps.Include
- Containers.Indefinite_Hashed_Maps.Insert
- Containers.Indefinite_Hashed_Maps.Replace
- Containers.Indefinite_Hashed_Maps.Replace_Element
-
- Containers.Indefinite_Hashed_Sets.Insert
- Containers.Indefinite_Hashed_Sets.Include
- Containers.Indefinite_Hashed_Sets.Replace
- Containers.Indefinite_Hashed_Sets.Replace_Element
- Containers.Indefinite_Hashed_Sets.To_Set
-
- Containers.Indefinite_Hashed_Sets.Generic_Keys.Replace
-
- Containers.Indefinite_Multiway_Trees.Append_Child
- Containers.Indefinite_Multiway_Trees.Insert_Child
- Containers.Indefinite_Multiway_Trees.Prepend_Child
- Containers.Indefinite_Multiway_Trees.Replace_Element
-
- Containers.Indefinite_Ordered_Maps.Include
- Containers.Indefinite_Ordered_Maps.Insert
- Containers.Indefinite_Ordered_Maps.Replace
- Containers.Indefinite_Ordered_Maps.Replace_Element
-
- Containers.Indefinite_Ordered_Multisets.Insert
- Containers.Indefinite_Ordered_Multisets.Replace_Element
- Containers.Indefinite_Ordered_Multisets.To_Set
-
- Containers.Indefinite_Ordered_Sets.Include
- Containers.Indefinite_Ordered_Sets.Insert
- Containers.Indefinite_Ordered_Sets.Replace
- Containers.Indefinite_Ordered_Sets.Replace_Element
- Containers.Indefinite_Ordered_Sets.To_Set
-
- Containers.Indefinite_Ordered_Sets.Generic_Keys.Replace
-
- Containers.Indefinite_Holders.Replace_Element
- Containers.Indefinite_Holders.To_Holder
-
- Containers.Indefinite_Vectors."&"
- Containers.Indefinite_Vectors.Append
- Containers.Indefinite_Vectors.Insert
- Containers.Indefinite_Vectors.Prepend
- Containers.Indefinite_Vectors.Replace_Element
- Containers.Indefinite_Vectors.To_Vector
-
-If a subprogram requires indefinite allocation, 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 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 of an initialized allocator whose
-access type is declared immediately within the instance, where:
+presented in this clause are said to *perform indefinite allocation*. 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
+formal indefinite type and that are identified as performing indefinite
+allocation in the subclause defining the generic package.
+
+If a subprogram performs indefinite allocation, 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
+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
+of an initialized allocator whose access type is declared immediately within
+the instance, where:
- the initial value is the value of the parameter; and
@@ -110,9 +62,6 @@
- finalization of the collection of the access type has started if and
only if the finalization of the instance has started.
-[Question: Do we need to worry about accessibility checks on container stream
-input in this AI?] [Editor's comment: This sounds suspiciously Bairdian. ;-)]
-
AARM note:
The phrase "explicitly specified" means those checks for which section 4.8
includes the phrase "<some exception> is raised if ...". It does not refer,
@@ -133,14 +82,94 @@
started. We want to allow Program_Error to be propagated in this case
(as specified in 4.8(10.2/2,11.1/2)).
+
+At the end of A.18.11 (Containers.Indefinite_Vectors), add:
+
+Dynamic Semantics
+
+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).
+
+
+At the end of A.18.12 (Containers.Indefinite_Doubly_Linked_Lists), add:
+
+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).
+
+
+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
+it's sufficient to mention the formal of type Element_Type.
+
+
+At the end of A.18.14 (Containers.Indefinite_Ordered_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
+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).
+
+AARM note: This also applies to the procedure Replace declared in the nested
+generic package Generic_Keys.
+
+
+At the end of A.18.16 (Containers.Indefinite_Ordered_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).
+
+AARM note: This also applies to the procedure Replace declared in the nested
+generic package Generic_Keys.
+
+
+At the end of A.18.17 (Containers.Indefinite_Multiway_Trees), add:
+
+Dynamic Semantics
+
+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).
+
+
+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:
-We want to be able to write the implementation of containers packages in Ada,
-and we expect the implementation to use allocators. As such, it would be odd if
-some of the reasons that those allocators could fail were not relected in the
-specification.
+We want to be able to write the implementation of containers packages in
+Ada, and we expect the implementation to use allocators. As such, it would
+be odd if some of the reasons that those allocators could fail were not
+reflected in the specification.
A grocery list of considerations for this solution:
@@ -189,24 +218,35 @@
--------------
The checks are only required on certain operations declared within certain
-instances of the indefinite containers. Specifically, they're needed when the
-actual types for the indefinite formal types (the Element_Type and Key_Type
-types) are class-wide types or indefinite subtypes with access discriminants,
-and for the operations that have parameters of those actual types that create
-and initialize container elements using those parameters. 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.
+instances of the indefinite containers. Specifically, they're needed when
+the actual types for the indefinite formal types (the Element_Type and
+Key_Type types) are class-wide types or indefinite subtypes with access
+discriminants, and for the operations that have parameters of those actual
+types that create and initialize container elements using those parameters.
+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.
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),
-which is why we have given a list of them. An alternative would be to add
-wording to each such operation in its respective section, but that still
-requires identifying them, and would seem to add unnecessary verbiage.
-
-Of course, the downside of specifically identifying the operations is that when
-any new such operations are added, the list will need to be updated to include
-them.
+which is why the subclause that defines each of the indefinite containers gives
+a list of the operations that perform indefinite allocation.
+
+Of course, the downside of specifically identifying the operations is
+that when any new such operations are added, the list will need to be
+updated to include them.
+
+One might wonder whether it's possible to stream in something whose
+accessibility is too shallow for the container. The check is against the
+element type of the container instance, and the contents have to live at
+least as long as that element type. Thus, anything we can stream out has
+already been checked. And thus anything that we can stream in is already OK.
+(Recall that we only promise to be able to stream in stuff that we stream out,
+not anything in general.) And we don't promise any extra interoperability
+for streaming of indefinite containers. (We do for the bounded and unbounded
+forms, but that doesn't apply to the indefinite forms.) If there were an
+interoperability promise, a less nested instance could cause trouble.
!example
@@ -544,5 +584,35 @@
indefinite containers.
[Followed by version /02 of the AI - Editor.]
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, June 10, 2013 1:45 AM
+
+Attached is the revision of AI12-0035 [This is version /03 of this AI - Editor],
+following the request of the last ARG meeting, eliminating the list of affected
+operations in A.18 and naming the sets of operations that perform indefinite
+allocation in the subclauses of each of the indefinite containers. I added
+those to the !wording as Dynamic Semantics, but perhaps they should simply be
+part of the Static Semantics in those subclauses, since they just state a
+property of the operations.
+
+I also revised the last paragraphs of the !discussion to reflect the choice of
+putting a list with each indefinite container, but I left the part at the
+beginning with the "grocery list" of considerations that Randy wrote. I'm not
+sure if that should be retained as is or rewritten. I also added a paragraph at
+the end of !discussion discussing the question about streams that was included
+in the minutes, explaining why streams aren't a problem.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 10, 2013 4:56 PM
+
+FYI, we almost never put the semantics of language-defined packages into Dynamic
+Semantics, it always goes into Static Semantics. Don't ask me to explain that
+(because I can't), but that's the way the RM is structured. So these should just
+be additional bullets at the end of the existing list.
****************************************************************
Questions? Ask the ACAA Technical Agent