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

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0262-1.txt

--- ai05s/ai05-0262-1.txt	2011/09/29 06:34:03	1.3
+++ ai05s/ai05-0262-1.txt	2011/10/21 06:42:22	1.4
@@ -1,4 +1,4 @@
-!standard  1.1.2(23)                               11-09-26    AI05-0262-1/03
+!standard  1.1.2(23)                               11-10-11    AI05-0262-1/03
 !standard  3.1(1)
 !standard  3.2.4(0)
 !standard  3.3(19)
@@ -30,9 +30,47 @@
 !standard  7.6.1(20)
 !standard 10.1.1(12.2/2)
 !standard 10.1.1(12.3/2)
+!standard 10.1.2(21/2)
+!standard 10.1.2(22/2)
 !standard 13.11(21)
+!standard 13.11.2(16)
+!standard 13.11.3(4)
+!standard  A.4.11(0)
+!standard  A.13(14)
+!standard  A.16(104/2)
+!standard  A.16(112/2)
+!standard  A.18.1(7/2)
+!standard  A.18.2(147/2)
+!standard  A.18.2(231/2)
+!standard  A.18.2(251/2)
+!standard  A.18.2(252/2)
+!standard  A.18.3(88/2)
+!standard  A.18.3(102/2)
+!standard  A.18.3(145/2)
+!standard  A.18.3(156/2)
+!standard  A.18.3(159/2)
+!standard  A.18.4(43/3)
+!standard  A.18.4(79/2)
+!standard  A.18.4(82/2)
+!standard  A.18.6(58/2)
+!standard  A.18.6(74/2)
+!standard  A.18.7(38/2)
+!standard  A.18.7(100/2)
+!standard  A.18.7(103/2)
+!standard  A.18.9(81/2)
+!standard  A.18.9(93/2)
 !standard  A.18.10(0)
 !standard  A.18.18(0)
+!standard  A.18.26(5/2)
+!standard  A.18.26(9/2)
+!standard  A.18.27(0)
+!standard  A.18.30(0)
+!standard  B.2(10.1/2)
+!standard  B.3(2/2)
+!standard  D.2.2(3.5/2)
+!standard  D.2.2(6.2/2)
+!standard  D.7(19.1/2)
+!standard  H.4(8/1)
 !class presentation 11-07-27
 !status Amendment 2012 11-07-27
 !status work item 11-07-27
@@ -128,7 +166,7 @@
 In a named_array_aggregate {where all discrete_choices are static}[with more than one discrete_choice],
 no two discrete_choices are allowed to cover the same value (see 3.8.1); if there is no others choice,
 the discrete_choices taken together shall exactly cover a contiguous sequence of values of the
-corresponding index type. 
+corresponding index type.
 
 AARM Reason: This has to apply even if there is only one static discrete_choice; a single choice
 has to represent a contiguous range (a subtype_mark with a static predicate might represent a
@@ -224,6 +262,15 @@
 postconditions are considered to be @i<enabled> for that subprogram or
 entry.
 
+Modify 6.1.1(20/3):
+
+"{Within a postcondition expression, d}[D]enotes the value of X at the beginning of the
+execution of  the subprogram or entry {to which the postcondition applies}..."
+
+Split from 6.1.1(23/3):
+
+"Use of this attribute is allowed only within a postcondition expression for F."
+
 Modify 6.1.1(27/3):
 
 "... For [a task or protected]{an} entry call..."
@@ -236,8 +283,22 @@
 
 "...subprogram {or entry}."
 
-Modify 6.1.1(33/3) by deleting the last sentence.
+Modify 6.1.1(30/3):
+"... the checks that are performed [that]{to} verify ..."
 
+Modify 6.1.1(33/3) by deleting the last sentence and replacing it by:
+
+For a dispatching call, if the assertion policy in effect at the point of the
+declaration of the denoted callable entity is not the same as the assertion
+policy in effect at the point of the declaration of the invoked callable entity,
+it is implementation defined whether any precondition or postcondition checks
+are made.
+
+AARM Discussion: For a dispatching call with different policies, whether a check
+is made probably will be different for different checks, depending on whether
+the implementation makes them at the call site, in a wrapper, or inside the
+called subprogram or entry.
+
 Modify 6.1.1(35/3):
 
 "...[may]{need} not..."  ["May not" is not allowed by ISO drafting rules - ED].
@@ -280,11 +341,114 @@
 
 Modify 10.1.1(12.2/3) and 10.1.1(12.3/3): "...{immediately within}[directly in]..."
 
+Modify 10.1.2(21/3) and 10.1.2(22/3) by replacing "which" with "that".
+
+
+Modify the end of 13.11(21.1/3):
+"...whose pool is P[ and]{, only at the following points}:
+
 Modify the start of 13.11(21.5/3):
 
 For [one]{each} of the calls of Allocate described above, P
 (equivalent to T'Storage_Pool) is passed as the Pool parameter. ...
 
+Replace the first sentence of 13.11.2(16/3) with:
+"Evaluating a name that denotes a nonexistent object, or a protected subprogram or subprogram renaming
+whose associated object (if any) is nonexistent, is erroneous."
+
+Add to the end of AARM 13.11.2(16.a/3):
+"The part about a subprogram renaming is intended to cover the case of a renaming of a prefixed view
+where the prefix object has been deallocated, or the case of a renaming of an entry or protected
+subprogram where the associated task or protected object has been deallocated."
+
+
+Modify A.4.11(46/3):
+
+"...defined by Annex C of ISO/IEC 10646 in 8 bits, big{-}endian
+{order}; and UTF_16LE corresponds to the UTF-16 encoding
+scheme {in}[on] 8 bits, little{-}endian {order}.
+
+Modify A.4.11(48/3): "...BOM-16LE{,} and..."
+
+Modify A.4.11(54/3 and 55/3):
+
+"...code[-]{ }point..."
+
+Modify A.4.11(56/3): "... In particular{,} the characters ..."
+
+Modify A.4.11(58/3): "... [which]{that} ...".
+
+Add after A.4.11(58/3):
+
+   Each of the Encode functions takes a String, Wide_String, or Wide_Wide_String Item parameter that
+   is assumed to be an array of unencoded characters. Each of the Convert functions takes a UTF_String
+   (respectively UTF_8_String and UTF_16_String) Item parameter that is assumed to contain characters
+   whose position values correspond to a valid encoding sequence according to the encoding scheme
+   required by the function or specified by its Input_Scheme parameter.
+
+Modify A.4.11(72/3, 84/3, 96/3): "... UTF-16LE{,} ..."
+
+For the description of all of the Encode functions in A.4.11, modify them similarly to the below:
+
+{Returns the value of Item}[Encodes from String input, and generates an output] encoded in
+UTF-8, UTF-16LE or UTF-16BE [encoding] as specified by Output_Scheme.
+
+For the description of all of the Decode functions in A.4.11, modify them similarly to the below:
+
+{Returns the result of decoding Item, which is}[Decodes from input] encoded in UTF-8[, and returns
+the corresponding String value].
+
+For the description of all of the Convert functions in A.4.11, modify them similarly to the below:
+
+{Returns the value of Item (}[Converts from input] originally encoded in UTF-16{)}[ and generates an output]
+encoded in UTF-8.
+
+Add after A.13(14):
+
+These exceptions are also propagated by various other language-defined packages and operations, see
+the definition of those entities for other reasons that these exceptions are propagated.
+
+AARM Reason: This clause is based in Ada 95. Later versions of Ada (starting with Technical Corrigendum 1)
+have added a number of additional places and reasons that cause these exceptions. In particular, TC1
+says that stream attributes need to raise End_Error in some circumstances; Ada 2005 adds Ada.Directories
+and a number of new places and reasons that Name_Error and Use_Error are raised. There are more. We don't
+want to try to update this text (or even this note!) for every possible reason and place that might
+raise one of these exceptions, so we add this blanket statement.
+
+[It's unfortunate that all of the places that exceptions are "propagated" by language-defined subprograms
+is not indexed, but that would be a huge amount of work - Editor.]
+
+Modify the first sentence of A.16(104/3, 112/3): "... matching Pattern {and Filter}. ..."
+
+Add after A.18.1(7/2):
+
+"Capacity_Error is raised when the capacity of a container is exceeded."
+
+Modify A.18.2(147.20/3): "...setting [Target's] {the} length {of Target} to be that of Source)."
+
+Modify A.18.2(231/3), A.18.3(145/3), A.18.26(5/3), A.18.26(9/3): "... [How many]{The number of} times..."
+
+Modify A.18.2(251/2), A.18.3(156/2), A.18.4(79/2), A.18.7(100/2): "...that [contains]{previously
+contained} the ..."
+
+Modify A.18.2(252/2), A.18.3(159/2), A.18.4(82/2), A.18.7(103/2):
+"..object{ and changing the length of the target object to the length of the source object}."
+
+Modify A.18.3(88/3), A.18.4(43/3), A.18.7(38/3): "... Otherwise, {the operation is} equivalent..."
+
+Replace A.18.3(102/3):
+
+If Length (Container) <= Count, then Delete_First is equivalent to Clear (Container).
+Otherwise, it removes the first Count nodes from Container.
+
+In A.18.6(58/2) and A.18.9(81/2), put "predecessor" in italics and add an index entry.
+
+Modify A.18.6(74/2): "...Otherwise{,} Previous returns a cursor designating the
+{predecessor }node {of}[that precedes] the one ..."
+
+Modify A.18.9(93/2): "...Otherwise{,} Previous returns a cursor designating the
+{predecessor }element {of}[that precedes] the one ..."
+
 Modify A.18.10(3/3):
 
 ...and has [no]{neither an} associated element value {nor any parent node}. ...
@@ -295,39 +459,56 @@
 
 Modify A.18.10(92/3): "... and a cursor [designated] {designating} the corresponding child..."
 
-Modify A.18.10(94/3): "...  with [a] cursor{s} designating the root node{s} of Left 
+Modify A.18.10(94/3): "...  with [a] cursor{s} designating the root node{s} of Left
 and Right."
 
 Modify A.18.10(143/3): "... The search [checks] {traverses}..."
 
-Modify A.18.10(145/3): 
+Modify A.18.10(145/3):
 "Find_In_Subtree searches [a subtree of the elements of Container]
 {the subtree rooted by Position} for an element equal to Item (using..."
 "... The search [checks] {traverses}..."
 
 Modify A.18.10(161/3): "...; [in this case] Program_Error..."
 
-Modify A.18.10(162/3, 165/3, 167/3): 
+Modify A.18.10(162/3, 165/3, 167/3):
 
 "...and {Parent does not designate the parent node of of the node designated by Before}[Container.Parent (Before)
 is not equal to Parent], then..."
 
 Replace "dependent elements" in A.18.10(173/3) with "descendant nodes".
 
-Modify A.18.10(175/3, 177/3, 180/3): 
+Modify A.18.10(175/3, 177/3, 180/3):
 
 "...and {Parent does not designate the parent node of of the node designated by Before}[Target.Parent (Before)
 is not equal to Parent], then..."
 
-Modify A.18.10(182/3, 189/3): 
+Modify A.18.10(182/3, 189/3):
 
 "...and {Target_Parent does not designate the parent node of of the node designated by Before}[Target.Parent (Before)
 is not equal to Target_Parent], then..."
+
+Modify A.18.10(228/3):
+"..object{ and changing the node count of the target object to that of the source object}."
+
+Modify A.18.18(29/3, 30/3, 48/3, 49/3, 57/3, 60/3, 67/3): "tamper with elements" should be "tamper with the element".
+
+Modify A.18.27(10/3): "...{is allowed to}[may]..."
+
+Modify A.18.30(17/3): "... otherwise{,} Success..."
+
+In B.2(10.1/2), delete "following".
+
+Modify B.3(2/2): "...types, constants{,} and ..."
+
+Modify D.2.2(3.5/2): "...one or more Priority_Specific_Dispatching pragmas{,} the
+dispatching policy..."
 
-Modify A.18.18(29/3, 30/3, 48/3, 49/3, 57/3, 60/3, 67/3):
+Modify D.2.2(6.2/2): "...one or more Priority_Specific_Dispatching pragmas{,} a task dispatching point..."
 
-"tamper with elements" should be "tamper with the element".
+Modify D.7(19.3/3): "At run[-]{ }time, ..."
 
+Replace H.4(8.1/3) with "There are no allocators of anonymous access types."
 
 !discussion
 
@@ -342,12 +523,46 @@
 wording is dubious. The formal definition in 6.1.1(18/3) is correct, but too wordy to use
 in this introductory text.
 
+6.1.1(33/3): We don't want the fact that checks can be turned on or off to affect the
+implementation. In the case of a dispatching call, checks made at the call site
+might have a different assertion policy than checks made in the subprogram body
+(or in a wrapper). So we don't specify whether those checks are made in that case. We
+expect that most users will turn assertions on or off for the whole program anyway, in
+which case this won't make any difference.
+
 7.4(6/3): There is no matching defined between constraints and subtypes. We have to match
 two constraints.
 
 10.1.1(12.2/3, 12.3/3): "directly in" is not defined, while "immediately within" is a
 defined term, so we prefer that.
 
+13.11.2(16/3): It was pointed out that there were similar cases for subprogram renamings,
+as explained in the AARM note.
+
+A.4.11(58/3): We need to say that the parameters to Encode and Convert are assumed to be
+of the right form; for some reason, we only said that for Decode. In particular, none of
+the Encode functions make any effort to determine whether the Item parameter is already
+encoded (beyond checking for illegal characters).
+
+A.4.11 function descriptions: The only purpose to these descriptions is to give the encodings for
+the parameter and/or result; all of the other rules are given in the blanket paragraphs at
+the start. Thus we want these are simple as possible.
+
+A.18.2(252/2), A.18.3(159/2), A.18.4(82/2), A.18.7(103/2), A.18.10(228/3): An unfriendly reading
+of this text could cause one to imagine that the Length of the target is unchanged (if long
+enough). So we added some additional wording to ensure that no one thinks that.
+
+A.18.3(102/3): We replace the wording proposed in AI05-0021-1 with wording parallel to that
+for Delete_Last. The previous wording raised Constraint_Error when deleting from an empty
+container using Delete_First, but that doesn't make much sense: the result of the operation
+ought to be a empty container (it is always allowed to ask to delete more nodes than are
+present).
+
+
+
+A.18.6(58/2) and A.18.9(81/2): These are the defining occurrences; only ordered forms have
+"predecessors".
+
 A.18.10(162/3, 165/3, 167/3, 175/3, 177/3, 180/3, 182/3, 189/3): The Container.Parent (Before)
 text was supposed to represent a prefix call. Unfortunately, the function Parent has
 no Container parameter, so this call is impossible. In addition, most of these functions
@@ -355,7 +570,12 @@
 wording to give the full definition of the Parent operation; it's not that much longer
 and it prevents any confusion.
 
+B.2(10.1/3): This text occurs in the middle of B.2, and then talks about the "following"
+clauses. It should apply to the whole Annex, because clearly we don't want people supporting,
+say, the Export aspect in some bizarre way for a foreign language.
+
 
+
 !corrigendum 1.1.2(23)
 
 @dinsa
@@ -384,7 +604,7 @@
 An @fa<object_declaration> declares a @i<stand-alone> object with a given nominal
 subtype and, optionally, an explicit initial value given by an initialization expression.
 For an array, task, or protected object, the @fa<object_declaration> may include the
-definition of the (anonymous) type of the object. 
+definition of the (anonymous) type of the object.
 
 !corrigendum 3.5(30/2)
 
@@ -473,12 +693,12 @@
 In a @fa<named_array_aggregate> with more than one @fa<discrete_choice>, no two
 @fa<discrete_choice>s are allowed to cover the same value (see 3.8.1); if there is no @b<others> choice,
 the @fa<discrete_choice>s taken together shall exactly cover a contiguous sequence of values of the
-corresponding index type. 
+corresponding index type.
 @dby
 In a @fa<named_array_aggregate> where all @fa<discrete_choice>s are static, no two
 @fa<discrete_choice>s are allowed to cover the same value (see 3.8.1); if there is no @b<others> choice,
 the @fa<discrete_choice>s taken together shall exactly cover a contiguous sequence of values of the
-corresponding index type. 
+corresponding index type.
 
 
 !corrigendum 4.5.2(2)
@@ -556,7 +776,7 @@
 @fa<qualified_expression> whose @fa<subtype_mark> denotes a static and
 constrained scalar subtype, then each non-@b<others> @fa<discrete_choice>
 shall cover only values in that subtype, and each value of that
-subtype shall be covered by some @fa<discrete_choice> 
+subtype shall be covered by some @fa<discrete_choice>
 (either explicitly or by @b<others>).>
 @dby
 @Xbullet<If the @i<selecting_>@fa<expression> is a @fa<name> (including a
@@ -721,7 +941,7 @@
 @dinsa
 @xbullet<For a Finalize invoked by a transfer of control due to an abort or selection
 of a terminate alternative, the exception is ignored; any other finalizations due to
-be performed are performed.>   
+be performed are performed.>
 @dinst
 @s8<@i<Implementation Permissions>>
 
@@ -757,7 +977,28 @@
 @fa<discriminant_part>; if the @fa<type_declaration> is tagged, then the view
 is a tagged incomplete view.>
 
+!corrigendum 10.1.2(21/2)
+
+@drepl
+@xbullet<in the same @fa<context_clause> as, or within the scope of, a
+@fa<nonlimited_with_clause> that mentions the same library package; or>
+@dby
+@xbullet<within a @fa<context_clause> for a @fa<library_item> that is
+within the scope of a @fa<nonlimited_with_clause> that mentions the same
+library package; or>
+
+!corrigendum 10.1.2(22/2)
 
+@drepl
+@xbullet<in the same @fa<context_clause> as, or within the scope of, a
+@fa<use_clause> that names an entity declared within the declarative region of
+the library package.>
+@dby
+@xbullet<within a @fa<context_clause> for a @fa<library_item> that is within the
+scope of a @fa<use_clause> that names an entity declared in the declarative
+region of the library package.>
+
+
 !corrigendum 13.11(21)
 
 @dinsa
@@ -784,6 +1025,333 @@
 block of memory of Size_In_Storage_Elements storage elements. Any exception
 propagated by Allocate is propagated by the construct that contained the call.
 
+!corrigendum 13.11.2(16)
+
+@drepl
+Evaluating a name that denotes a nonexistent object is erroneous. The execution of a call
+to an instance of Unchecked_Deallocation is erroneous if the object was created other
+than by an @fa<allocator> for an access type whose pool is Name'Storage_Pool.
+@dby
+Evaluating a name that denotes a nonexistent object, or a protected subprogram or
+subprogram renaming whose associated object (if any) is nonexistent, is erroneous.
+The execution of a call to an instance
+of Unchecked_Deallocation is erroneous if the object was created other than
+by an @fa<allocator> for an access type whose pool is Name'Storage_Pool.
+
+!corrigendum 13.11.3(4)
+
+@drepl
+The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Controlled shall denote a
+non-derived access subtype.
+@dby
+The @i<storage_pool_>@fa<name> shall denote a variable.
+
+If the @fa<pragma> is used as a configuration pragma, the @fa<storage_pool_indicator>
+shall be @b<null>, and it defines the @i<default pool> to be @b<null> within all
+applicable compilation units (see 10.1.5), except within the immediate scope of
+another @fa<pragma> Default_Storage_Pool. Otherwise, Redundant[the pragma occurs
+immediately within a sequence of declarations, and] it defines the default pool
+within the immediate scope of the pragma to be either null or the pool denoted
+by the @i<storage_pool_>@fa<name>, except within the immediate scope of a later pragma
+Default_Storage_Pool. Thus, an inner pragma overrides an outer one.
+
+A @fa<pragma> Default_Storage_Pool shall not be used as a configuration pragma
+that applies to a compilation unit that is within the immediate scope of
+another @fa<pragma> Default_Storage_Pool.
+
+
+!corrigendum A.4.11(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+
+!corrigendum A.13(14)
+
+@dinsa
+The exception Layout_Error is propagated (in text input-output) by Col, Line, or Page
+if the value returned exceeds Count'Last. The exception Layout_Error is also propagated
+on output by an attempt to set column or line numbers in excess of specified maximum
+line or page lengths, respectively (excluding the unbounded cases). It is also propagated
+by an attempt to Put too many characters to a string.
+@dinst
+These exceptions are also propagated by various other language-defined packages and
+operations, see the definition of those entities for other reasons that these exceptions
+are propagated.
+
+
+!corrigendum A.16(104/2)
+
+@drepl
+@xindent<Starts a search in the directory named by Directory for entries
+matching Pattern. Pattern represents a pattern for matching file names. If
+Pattern is null, all items in the directory are matched; otherwise, the
+interpretation of Pattern is implementation-defined. Only items that match
+Filter will be returned. After a successful call on Start_Search, the object
+Search may have entries available, but it may have no entries available if no
+files or directories match Pattern and Filter. The exception Name_Error is
+propagated if the string given by Directory does not identify an existing
+directory, or if Pattern does not allow the identification of any possible
+external file or directory. The exception Use_Error is propagated if the
+external environment does not support the searching of the directory with the
+given name (in the absence of Name_Error). When Start_Search propagates
+Name_Error or Use_Error, the object Search will have no entries available.>
+@dby
+@xindent<Starts a search in the directory named by Directory for entries
+matching Pattern and Filter. Pattern represents a pattern for matching file names. If
+Pattern is the null string, all items in the directory are matched; otherwise,
+the interpretation of Pattern is implementation-defined. Only items that match
+Filter will be returned. After a successful call on Start_Search, the object
+Search may have entries available, but it may have no entries available if no
+files or directories match Pattern and Filter. The exception Name_Error is
+propagated if the string given by Directory does not identify an existing
+directory, or if Pattern does not allow the identification of any possible
+external file or directory. The exception Use_Error is propagated if the
+external environment does not support the searching of the directory with the
+given name (in the absence of Name_Error). When Start_Search propagates
+Name_Error or Use_Error, the object Search will have no entries available.>
+
+!corrigendum A.16(112/2)
+
+@drepl
+@xindent<Searches in the directory named by Directory for entries matching
+Pattern. The subprogram designated by Process is called with each matching entry
+in turn. Pattern represents a pattern for matching file names. If Pattern is
+null, all items in the directory are matched; otherwise, the interpretation of
+Pattern is implementation-defined. Only items that match Filter will be
+returned. The exception Name_Error is propagated if the string given by
+Directory does not identify an existing directory, or if Pattern does not allow
+the identification of any possible external file or directory. The exception
+Use_Error is propagated if the external environment does not support the
+searching of the directory with the given name (in the absence of Name_Error).>
+@dby
+@xindent<Searches in the directory named by Directory for entries matching
+Pattern and Filter. The subprogram designated by Process is called with each matching entry
+in turn. Pattern represents a pattern for matching file names. If Pattern is the
+null string, all items in the directory are matched; otherwise, the
+interpretation of Pattern is implementation-defined. Only items that match
+Filter will be returned. The exception Name_Error is propagated if the string
+given by Directory does not identify an existing directory, or if Pattern does
+not allow the identification of any possible external file or directory. The
+exception Use_Error is propagated if the external environment does not support
+the searching of the directory with the given name (in the absence of
+Name_Error).>
+
+
+!corrigendum A.18.1(7/2)
+
+@drepl
+Hash_Type represents the range of the result of a hash function. Count_Type represents
+the (potential or actual) number of elements of a container.
+@dby
+Capacity_Error is raised when the capacity of a container is exceeded.
+
+!corrigendum A.18.2(147/2)
+
+@dinsa
+Force a conflict; the real text is found in the conflict file.
+@dinst
+Nothing.
+
+!corrigendum A.18.2(231/2)
+
+@drepl
+The actual function for the generic formal function "<" of Generic_Sorting is
+expected to return the same value each time it is called with a particular pair
+of element values. It should define a strict ordering relationship, that is, be
+irreflexive, asymmetric, and transitive; it should not modify Container. If the
+actual for "<" behaves in some other manner, the behavior of the subprograms of
+Generic_Sorting are unspecified. How many times the subprograms of Generic_Sorting
+call "<" is unspecified.
+@dby
+The actual function for the generic formal function "<" of Generic_Sorting is
+expected to return the same value each time it is called with a particular pair
+of element values. It should define a strict weak ordering relationship (see A.18);
+it should not modify Container. If the
+actual for "<" behaves in some other manner, the behavior of the subprograms of
+Generic_Sorting are unspecified. The number of times the subprograms of Generic_Sorting
+call "<" is unspecified.
+
+!corrigendum A.18.2(251/2)
+
+@drepl
+@xbullet<The element it designates has been deleted.>
+@dby
+@xbullet<The element it designates has been deleted or removed from the vector
+that previously contained the element.>
+
+!corrigendum A.18.2(252/2)
+
+@drepl
+The execution of an @fa<assignment_statement> for a vector shall have the effect of
+copying the elements from the source vector object to the target vector object.
+@dby
+The execution of an @fa<assignment_statement> for a vector shall have the effect of
+copying the elements from the source vector object to the target vector object
+and changing the length of the target object to that of the source object.
+
+!corrigendum A.18.3(88/2)
+
+@drepl
+@xindent<If Target denotes the same object as Source, then Move has no effect. Otherwise,
+Move first calls Clear (Target). Then, the nodes in Source are moved to Target (in the
+original order). The length of Target is set to the length of Source, and the length of
+Source is set to 0.>
+@dby
+@xindent<If Target denotes the same object as Source, then the operation has no effect.
+Otherwise, the operation is equivalent to Assign (Target, Source) followed by Clear (Source).>
+
+!corrigendum A.18.3(102/2)
+
+@drepl
+@xindent<Equivalent to Delete (Container, First (Container), Count).>
+@dby
+@xindent<If Length (Container) <= Count, then Delete_First is equivalent to Clear (Container).
+Otherwise, it removes the first Count nodes from Container.>
+
+!corrigendum A.18.3(145/2)
+
+@drepl
+The actual function for the generic formal function "<" of Generic_Sorting is
+expected to return the same value each time it is called with a particular pair
+of element values. It should define a strict ordering relationship, that is,
+be irreflexive, asymmetric, and transitive; it should not modify Container. If
+the actual for "<" behaves in some other manner, the behavior of the subprograms
+of Generic_Sorting are unspecified. How many times the subprograms of Generic_Sorting
+call "<" is unspecified.
+@dby
+The actual function for the generic formal function "<" of Generic_Sorting is
+expected to return the same value each time it is called with a particular pair
+of element values. It should define a strict weak ordering relationship (see A.18);
+it should not modify Container. If
+the actual for "<" behaves in some other manner, the behavior of the subprograms
+of Generic_Sorting are unspecified. The number of times the subprograms of Generic_Sorting
+call "<" is unspecified.
+
+!corrigendum A.18.3(156/2)
+
+@drepl
+@xbullet<The element it designates has been deleted.>
+@dby
+@xbullet<The element it designates has been removed from the list that
+previously contained the element.>
+
+!corrigendum A.18.3(159/2)
+
+@drepl
+The execution of an @fa<assignment_statement> for a list shall have the effect of
+copying the elements from the source list object to the target list object.
+@dby
+The execution of an @fa<assignment_statement> for a list shall have the effect of
+copying the elements from the source list object to the target list object
+and changing the length of the target object to that of the source object.
+
+!corrigendum A.18.4(43/2)
+
+@drepl
+@xindent<If Target denotes the same object as Source, then Move has no effect. Otherwise, Move first
+calls Clear (Target). Then, each node from Source is removed from Source and inserted into
+Target. The length of Source is 0 after a successful call to Move.>
+@dby
+@xindent<If Target denotes the same object as Source, then the operation has no effect. Otherwise,
+the operation is equivalent to Assign (Target, Source) followed by Clear (Source).>
+
+!corrigendum A.18.4(79/2)
+
+@drepl
+@xbullet<The node it designates has been deleted from the map.>
+@dby
+@xbullet<The node it designates has been removed from the map that previously
+contained the element.>
+
+!corrigendum A.18.4(82/2)
+
+@drepl
+The execution of an @fa<assignment_statement> for a map shall have the effect of
+copying the elements from the source map object to the target map object.
+@dby
+The execution of an @fa<assignment_statement> for a map shall have the effect of
+copying the elements from the source map object to the target map object
+and changing the length of the target object to that of the source object.
+
+!corrigendum A.18.6(58/2)
+
+@drepl
+The first node of a nonempty map is the one whose key is less than the key of
+all the other nodes in the map. The last node of a nonempty map is the one
+whose key is greater than the key of all the other elements in the map. The
+successor of a node is the node with the smallest key that is larger than the
+key of the given node. The predecessor of a node is the node with the largest
+key that is smaller than the key of the given node. All comparisons are done
+using the generic formal "<" operator for keys.
+@dby
+The @i<first node> of a nonempty map is the one whose key is less than the key of
+all the other nodes in the map. The @i<last node> of a nonempty map is the one
+whose key is greater than the key of all the other elements in the map. The
+@i<successor> of a node is the node with the smallest key that is larger than the
+key of the given node. The @i<predecessor> of a node is the node with the largest
+key that is smaller than the key of the given node. All comparisons are done
+using the generic formal "<" operator for keys.
+
+!corrigendum A.18.6(74/2)
+
+@drepl
+If Position equals No_Element, then Previous returns No_Element. Otherwise, Previous
+returns a cursor designating the node that precedes the one designated by Position.
+If Position designates the first element, then Previous returns No_Element.
+@dby
+If Position equals No_Element, then Previous returns No_Element. Otherwise, Previous
+returns a cursor designating the predecessor node of the one designated by Position.
+If Position designates the first element, then Previous returns No_Element.
+
+!corrigendum A.18.7(100/2)
+
+@drepl
+@xbullet<The element it designates has been deleted from the set.>
+@dby
+@xbullet<The element it designates has been removed from the set that previously
+contained the element.>
+
+!corrigendum A.18.7(103/2)
+
+@drepl
+The execution of an @fa<assignment_statement> for a set shall have the effect of
+copying the elements from the source set object to the target set object.
+@dby
+The execution of an @fa<assignment_statement> for a set shall have the effect of
+copying the elements from the source set object to the target set object
+and changing the length of the target object to that of the source object.
+
+!corrigendum A.18.9(81/2)
+
+@drepl
+The first element of a nonempty set is the one which is less than all the other
+elements in the set. The last element of a nonempty set is the one which is greater
+than all the other elements in the set. The successor of an element is the smallest
+element that is larger than the given element. The predecessor of an element is the
+largest element that is smaller than the given element. All comparisons are done
+using the generic formal "<" operator for elements.
+@dby
+The @i<first element> of a nonempty set is the one which is less than all the other
+elements in the set. The @i<last element> of a nonempty set is the one which is greater
+than all the other elements in the set. The @i<successor> of an element is the smallest
+element that is larger than the given element. The @i<predecessor> of an element is the
+largest element that is smaller than the given element. All comparisons are done
+using the generic formal "<" operator for elements.
+
+!corrigendum A.18.9(93/2)
+
+@drepl
+If Position equals No_Element, then Previous returns No_Element. Otherwise Previous
+returns a cursor designating the element that precedes the one designated by Position.
+If Position designates the first element, then Previous returns No_Element.
+@dby
+If Position equals No_Element, then Previous returns No_Element. Otherwise, Previous
+returns a cursor designating the predecessor element of the one designated by Position.
+If Position designates the first element, then Previous returns No_Element.
+
+
 !corrigendum A.18.10(0)
 
 @dinsc
@@ -796,6 +1364,149 @@
 
 Force a conflict; the real text is found in the conflict file.
 
+!corrigendum A.18.26(5/2)
+
+@drepl
+@xindent<The actual function for the generic formal function "<" of Generic_Array_Sort is
+expected to return the same value each time it is called with a particular pair
+of element values. It should define a strict ordering relationship, that is,
+be irreflexive, asymmetric, and transitive; it should not modify Container.
+If the actual for "<" behaves in some other manner, the behavior of the instance
+of Generic_Array_Sort is unspecified. How many times Generic_Array_Sort calls
+"<" is unspecified.>
+@dby
+@xindent<The actual function for the generic formal function "<" of Generic_Array_Sort is
+expected to return the same value each time it is called with a particular pair
+of element values. It should define a strict weak ordering relationship (see A.18);
+it should not modify Container.
+If the actual for "<" behaves in some other manner, the behavior of the instance
+of Generic_Array_Sort is unspecified. The number of times Generic_Array_Sort calls
+"<" is unspecified.>
+
+!corrigendum A.18.26(9/2)
+
+@drepl
+@xindent<The actual function for the generic formal function "<" of Generic_Constrained_Array_Sort
+is expected to return the same value each time it is called with a particular pair
+of element values. It should define a strict ordering relationship, that is,
+be irreflexive, asymmetric, and transitive; it should not modify Container.
+If the actual for "<" behaves in some other manner, the behavior of the instance
+of Generic_Constrained_Array_Sort is unspecified. How many times
+Generic_Constrained_Array_Sort calls "<" is unspecified.>
+@dby
+@xindent<The actual function for the generic formal function "<" of Generic_Constrained_Array_Sort
+is expected to return the same value each time it is called with a particular pair
+of element values. It should define a strict weak ordering relationship (see A.18);
+it should not modify Container.
+If the actual for "<" behaves in some other manner, the behavior of the instance
+of Generic_Constrained_Array_Sort is unspecified. The number of times
+Generic_Constrained_Array_Sort calls "<" is unspecified.>
+
+
+!corrigendum A.18.27(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+!corrigendum A.18.30(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+
+!corrigendum B.2(10.1/2)
+
+@drepl
+Support for interfacing to any foreign language is optional. However, an implementation
+shall not provide any attribute, library unit, or pragma having the same name as an attribute,
+library unit, or pragma (respectively) specified in the following clauses of this Annex unless
+the provided construct is either as specified in those clauses or is more limited in capability
+than that required by those clauses. A program that attempts to use an unsupported capability
+of this Annex shall either be identified by the implementation before run time or shall raise
+an exception at run time.
+@dby
+Support for interfacing to any foreign language is optional. However, an implementation
+shall not provide any aspect, attribute, library unit, or pragma having the same name as an
+aspect, attribute, library unit, or pragma (respectively) specified in the clauses of this Annex
+unless the provided construct is either as specified in those clauses or is more limited in
+capability than that required by those clauses. A program that attempts to use an unsupported
+capability of this Annex shall either be identified by the implementation before run time or
+shall raise an exception at run time.
+
+!corrigendum B.3(2/2)
+
+@drepl
+The package Interfaces.C contains the basic types, constants and subprograms
+that allow an Ada program to pass scalars and strings to C and C++ functions.
+When this clause mentions a C entity, the reference also applies to the
+corresponding entity in C++.
+@dby
+The package Interfaces.C contains the basic types, constants, and subprograms
+that allow an Ada program to pass scalars and strings to C and C++ functions.
+When this clause mentions a C entity, the reference also applies to the
+corresponding entity in C++.
+
+!corrigendum D.2.2(3.5/2)
+
+@drepl
+If a partition contains one or more Priority_Specific_Dispatching pragmas the
+dispatching policy for priorities not covered by any Priority_Specific_Dispatching
+pragmas is FIFO_Within_Priorities.
+@dby
+If a partition contains one or more Priority_Specific_Dispatching pragmas, the
+dispatching policy for priorities not covered by any Priority_Specific_Dispatching
+pragmas is FIFO_Within_Priorities.
+
+!corrigendum D.2.2(6.2/2)
+
+@drepl
+If a partition contains one or more Priority_Specific_Dispatching pragmas a task
+dispatching point occurs for the currently running task of a processor whenever
+there is a non-empty ready queue for that processor with a higher priority than
+the priority of the running task.
+@dby
+If a partition contains one or more Priority_Specific_Dispatching pragmas, a task
+dispatching point occurs for the currently running task of a processor whenever
+there is a non-empty ready queue for that processor with a higher priority than
+the priority of the running task.
+
+
+!corrigendum D.7(19.1/2)
+
+@dinsa
+@xhang<@xterm<Max_Entry_Queue_Length>
+Max_Entry_Queue_Length defines the maximum number of calls
+that are queued on an entry. Violation of this restriction
+results in the raising of Program_Error at the point of the call or requeue.>
+@dinss
+@xhang<@xterm<No_Standard_Allocators_After_Elaboration>>
+Specifies that an @fa<allocator> using a standard storage pool (see
+13.11) shall not occur within a parameterless library subprogram,
+nor within the @fa<handled_sequence_of_statements> of a task body. For
+the purposes of this rule, an @fa<allocator> of a type derived from a
+formal access type does not use a standard storage pool.
+
+@xindent<At run time, Storage_Error is raised if an @fa<allocator> using a
+standard storage pool is evaluated after the elaboration of the
+@fa<library_item>s of the partition has completed.>
+
+!corrigendum H.4(8/1)
+
+@dinsa
+@xhang<@xterm<No_Local_Allocators>@fa<Allocator>s are prohibited in subprograms,
+generic subprograms, tasks, and entry bodies.>
+@dinss
+@xhang<@xterm<No_Anonymous_Allocators>There are no @fa<allocator>s of anonymous access
+types.>
+
+@xhang<@xterm<No_Coextensions>There are no coextensions. See 3.10.2.>
+
+@xhang<@xterm<No_Access_Parameter_Allocators>@fa<Allocator>s are not permitted as the
+actual parameter to an access parameter. See 6.1.>
+
+
 !ACATS Test
 
 None needed.
@@ -1305,3 +2016,853 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Tuesday, September 27, 2011  9:58 PM
+
+Bob has in his review:
+
+> > 6.1.1(33/3)  If the assertion policy in effect at the point of a
+> > subprogram or entry
+> > declaration is Ignore, then no precondition or postcondition check
+> > is performed on a call on that subprogram or entry. If the assertion
+> > policy in
+> > effect at the point of a subprogram or entry declaration is Check,
+> > then preconditions and postconditions are considered to be enabled
+> > for that subprogram or entry.
+>
+> I'm concerned that we're not allowing preconditions to be checked at
+> the point of call, here, because at that point, we don't know (for
+> indirect calls) what assertion policy is in effect at the point of the
+> subp decl.
+>
+> I think perhaps the rules about policies should be relaxed.
+> Maybe we should say that Ignore really means "the implementation is
+> allowed to ignore", rather than "shall ignore".  Similar to check
+> suppression.
+
+I agree with this idea on general principles (note that I said something
+similar last week). But it's a pretty significant model change, and one
+that make the policy name "Ignore" much less intuitive.
+
+So we need to discuss this.
+
+Some points (in a Baird-like list):
+
+(1) Indirect calls via access-to-subprogram aren't very interesting WRT to
+    this, as the preconditions cannot be checked at the call site for those
+    in any case. (Access-to-subprogram types don't have preconditions, the
+    precondition of the designated subprogram has to be used, which means
+    at best a wrapper needs to be used. There would be no problem with a
+    wrapper.)
+
+(2) Formal subprograms have similar issues in a sharing implementation;
+    those also would use a wrapper.
+
+(3) Direct calls don't have a problem; they'll necessarily know what state
+    applies to the declaration.
+
+(4) What we really care about is dispatching calls. Here, specific preconditions
+    cannot be done at the call site anyway (by definition - they depend on the
+    actual subprogram). We definitely want the class-wide preconditions to be
+    done at the call site (the semantics essentially require that). That might
+    pose a problem with above definition.
+
+(5) We can solve this one case with a targeted rule (just as we did to allow
+    class-wide preconditions at the call site in the first place). The idea
+    would be that it is the definition of subprogram that is (statically)
+    called that determines the state, not necessarily the subprogram that is
+    (dynamically) called. That's where the class-wide precondition comes from,
+    and it would make sense that that is also where the policy should come.
+
+(6) I'm not as certain about what rule should apply to class-wide
+    postconditions; I can imagine either implementation being used and it
+    would be best if either policy could be used.
+
+(7) Maybe a better choice would be to say that if the policy of the
+    (statically) called subprogram and the subprogram dispatched to differ,
+    then it is unspecified which policy applies to a dispatching call.
+
+(8) Did I miss anything??
+
+(9) Any other ideas?
+
+(10) I do think we need to resolve this before publishing the Standard, as
+    it is pretty fundamental to the implementation of this feature, and it
+    would be nasty for the Standard to say something different than
+    implementations do. (Especially if we adopt Bob's original suggestion.)
+
+(11) Steve would find a generic contract violation or something, I'm afraid
+     I can't manage that.
+
+(12) I see the Red Sox managed to win a game, despite their best efforts to
+     blow it. [Editor's note: The Boston Red Sox managed to successfully (?)
+     complete (argubly) the worst collapse in Major League Baseball history,
+     blowing a 9 game lead with 24 games left in the season, the next night.
+     And the team that passed them in the standings lost 8 games during that
+     time.]
+
+(13) Do I have enough list points yet? ;-)
+
+(14) You can skip the points after #10, they are just me getting loopy.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, September 28, 2011  7:18 AM
+
+> ...[7 good points snipped]
+
+> (8) Did I miss anything??
+
+Any rules that complicate the implementation are of little value to users,
+because I suspect most people will turn the assertions on and off globally,
+rather than in a fine-grained manner.
+
+If this were the from-scratch design of a new language, I'd probably insist
+on nailing down the rule very tightly. But that's not our situation.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, September 28, 2011  7:42 AM
+
+> (6) I'm not as certain about what rule should apply to class-wide
+> postconditions; I can imagine either implementation being used and it
+> would be best if either policy could be used.
+>
+> (7) Maybe a better choice would be to say that if the policy of the
+> (statically) called subprogram and the subprogram dispatched to
+> differ, then it is unspecified which policy applies to a dispatching call.
+
+This seems fine to me.  We don't want this particular issue to significantly
+affect the overall implementation approach.
+
+I believe the reason we chose "ignore" was that we didn't want adding a
+precondition/postcondition ever to make programs *less* safe, presuming the
+setting is "Ignore."  Other policies such as "Assume_Without_Checking" could
+fall in the category of making the program less safe.  The rules on "suppress"
+are somewhat written that way, namely it is erroneous if you violate
+a check that is suppressed.   We did *not* want to make it erroneous
+to violate a precondition that is being "Ignore"d.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, September 28, 2011  8:02 PM
+
+> This seems fine to me.  We don't want this particular issue to
+> significantly affect the overall implementation approach.
+
+OK, so here's a stab at wording that:
+
+Add after the first sentence of 6.1.1(33/3) [note: the second sentence
+was moved to Static Semantics since the definition it makes it is used there.]
+
+For a dispatching call, if the assertion policy in effect at the point of the
+declaration of the denoted callable entity is not that same as the assertion
+policy in effect at the point of the declaration of the invoked callable entity,
+it is implementation-defined whether any precondition or postcondition checks
+are made.
+
+AARM Discussion: For a dispatching call with different policies, whether a check
+is made probably will be different for different checks, depending on whether
+the implementation makes them at the call site, in a wrapper, or inside the
+called subprogram or entry.
+
+Q. Should this be implementation-defined (requiring documentation) or unspecified?
+It's not clear to me that there is any real benefit to knowing how this is done,
+as (as Bob notes) most users will turn the checks on or off globally.
+
+> I believe the reason we chose "ignore" was that we didn't want adding
+> a precondition/postcondition ever to make programs
+> *less* safe, presuming the setting is "Ignore."  Other policies such
+> as "Assume_Without_Checking" could fall in the category of making the
+> program less safe.  The rules on "suppress" are somewhat written that
+> way, namely it is erroneous if you violate
+> a check that is suppressed.   We did *not* want to make it erroneous
+> to violate a precondition that is being "Ignore"d.
+
+That makes some sense, although it wouldn't necessarily prevent allowing the check
+to be made. One could imagine a rule where either the check is made, or it is not
+made and no assumptions can be made. Pure function calls are rather like that:
+you can assume that the result is the same, but if you make the call, you have
+to be prepared for a different result (you can't just ignore the result).
+
+Anyway, evaluating a precondition is a lot more likely to make a program less safe
+(via side-effects, erroneousness, etc.) than assuming that it is true (since it
+is rare that a compiler could usefully make such an assumption, since it probably
+doesn't have any body visibility, and Ada doesn't have a strong enough
+categorization to allow assuming a "safe" call). So I view your argument as weak.
+Even so, I think it is too late to change this unless there is a really strong
+reason, and clearly the above problem doesn't come anywhere near that level.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, September 30, 2011  8:11 PM
+
+Erhard had the following comment in his review:
+
+> A.4.11. 72/3 thru 106/3:
+>
+> drop the "," before the "and". Or else introduce it in 66 thru 70. Or
+> else ... whatever you do, do something consistent for the chapter.
+
+I asked Gary about this, and he had a similar set of reactions to mine:
+(1) The comma shouldn't be there;
+(2) But it seems to help readability in some of the paragraphs (especially 78/3,
+    90/3, 102/3);
+(3) Consistency is important;
+(4) Not quite sure what to do - either would be OK.
+
+I note that many of the functions elsewhere in the Standard start "Returns ...".
+
+In thinking about this, many of these sentences seem awkward. Consider the
+various encoding functions, exemplified by 86/3:
+
+   Encodes from Wide_String input, and generates an output encoded in UTF-8
+   encoding.
+
+"and generates an output"?? What's wrong with "returns"? And why is the type
+name in this text? -- anybody can see the type of the input from reading the
+profile on the line above. It would be a lot simpler to say:
+
+   Returns Item encoded in UTF-8 encoding.
+
+(or maybe "Returns the value of Item encoded in UTF-8 encoding.")
+
+and then we don't have to discuss whether a comma is needed or not. (I'm not
+sure if there is some important reason that J-P chose this wording, I'll let him
+tell us if there is.)
+
+In this case, it might be valuable to note that Item is not encoded (since a
+UTF_16_String would match this parameter), so maybe we should add:
+
+   Returns Item (which is assumed to not be encoded) encoded in UTF-8 encoding.
+
+But an alternative to that would be to mention that in a new paragraph following
+59/3 (so we only have to say it once):
+
+   The Item parameter to Encode functions is assumed to not be encoded; it is
+   treated as just an array of characters.
+
+We already have global sentences talking about the behavior of these functions,
+and the above is a lot clearer than anything stuck in the middle of the text.
+
+----
+
+The Decodes sentences are fine, and I'd leave the comma because it helps the
+readability as in 78/3:
+
+Decodes from input encoded in UTF-8, UTF-16LE, or UTF-16BE as specified by
+Input_Scheme, and returns the corresponding String value.
+
+I probably would have mentioned that parameter name rather than the generic
+"input", but it doesn't help enough to bother with changing:
+
+Decodes Item, which is assumed encoded in UTF-8, UTF-16LE, or UTF-16BE as
+specified by Input_Scheme, and returns the corresponding String value.
+
+(But at least here there is no argument about the comma :-)
+
+We probably don't need "corresponding" in the above, nor "String" (which is
+obvious from the function profile). So:
+
+Decodes Item, which is assumed encoded in UTF-8, UTF-16LE, or UTF-16BE as
+specified by Input_Scheme, and returns the value.
+
+Probably we can move the last part to the front:
+
+Returns the result of decoding Item, which is assumed encoded in UTF-8,
+UTF-16LE, or UTF-16BE as specified by Input_Scheme.
+
+----
+
+The Converts sentences is where the inconsistency arose, and seem to be the
+hardest to clean up. Consider 70/3:
+
+   Converts from input encoded in UTF-16 and generates an output encoded in
+   UTF-8.
+
+Combining the previous suggestions, we get:
+
+   Converts Item, which is assumed encoded in UTF-16, and returns the value
+   encoded in UTF-8.
+
+which doesn't seem quite right somehow.
+
+Maybe
+
+   Returns the value of Item, which is assumed encoded in UTF-16, encoded in
+   UTF-8.
+
+There being no important need to mention "Converts" here.
+
+--------------------------------
+
+Note in all of the above, I used "assumed" to be encoded or not encoded; that's
+because this interface has no strong typing and thus it is possible to pass a
+UTF-8 string to Encode (for instance). That's not going to cause Encode to
+magically morph into Convert, and it seems valuable to emphasize that fact.
+
+--------------------------------
+
+So to summarize, I'm proposing to overhaul A.4.11:
+
+Add a sentence after 59/3:
+
+   The Item parameter to each of the Encode functions is assumed to not be
+   encoded; it is treated as just an array of characters.
+
+and simplify all of the even numbered paragraphs starting with 62/3 (the parts
+in angle brackets would come from the similar text in the current wording):
+
+For Encodes:
+
+   Returns the value of Item <encoded in UTF-8 encoding>.
+
+For Decodes:
+
+   Returns the result of decoding Item, which is assumed <encoded in UTF-8,
+   UTF-16LE, or UTF-16BE as specified by Input_Scheme>.
+
+For Converts:
+
+   Returns the value of Item, which is assumed <encoded in UTF-16>, <encoded in
+   UTF-8>.
+
+This would allow me to not answer the question about the commas, and simplify
+the wording at the same time. (Given I've already spent more than an hour on
+this question, and the fix will take most of another hour in any case, it's
+probably worth the effort.)
+
+Further suggestions/simplifications welcome.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Saturday, October 1, 2011  12:33 AM
+
+> It would be a lot simpler to say:
+>
+>    Returns Item encoded in UTF-8 encoding.
+>
+> (or maybe "Returns the value of Item encoded in UTF-8 encoding.")
+>
+> and then we don't have to discuss whether a comma is needed or not.
+> (I'm not sure if there is some important reason that J-P chose this
+> wording, I'll let him tell us if there is.)
+
+This is all brand new text, don't assume some sophisticated hidden secret behind
+it... Just my misuse of english commas (there are some subtle differences in the
+use of comas between french and english).
+
+> Note in all of the above, I used "assumed" to be encoded or not
+> encoded; that's because this interface has no strong typing and thus
+> it is possible to pass a UTF-8 string to Encode (for instance). That's
+> not going to cause Encode to magically morph into Convert, and it
+> seems valuable to emphasize that fact.
+
+Interesting... Even if the string starts with a BOM? Maybe raising an exception
+would be appropriate. After all, if you encode an already encoded string, it is
+very likely to be a bug.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, October 1, 2011  2:03 AM
+
+> > It would be a lot simpler to say:
+> >
+> >    Returns Item encoded in UTF-8 encoding.
+> >
+> > (or maybe "Returns the value of Item encoded in UTF-8 encoding.")
+> >
+> > and then we don't have to discuss whether a comma is needed or not.
+> > (I'm not sure if there is some important reason that J-P chose this
+> > wording, I'll let him tell us if there is.)
+>
+> This is all brand new text, don't assume some sophisticated hidden
+> secret behind it... Just my misuse of english commas (there are some
+> subtle differences in the use of comas between french and english).
+
+That's what I expected, but I thought it was important to ask...
+
+> > Note in all of the above, I used "assumed" to be encoded or not
+> > encoded; that's because this interface has no strong typing and thus
+> > it is possible to pass a UTF-8 string to Encode (for instance).
+> > That's not going to cause Encode to magically morph into Convert,
+> > and it seems valuable to emphasize that fact.
+>
+> Interesting... Even if the string starts with a BOM? Maybe raising an
+> exception would be appropriate. After all, if you encode an already
+> encoded string, it is very likely to be a bug.
+
+You're asking me to justify the design decisions in a package you created??
+OK, here goes.
+
+You do have a check for "invalid" characters in a Wide_String; these include the
+BOM characters, so those would be detected (raising Encoding_Error). But you
+don't have any check for String (which makes sense, in that everything is valid
+there).
+
+That seems right to me. I wouldn't expect the Encoding routines to check for
+BOMs, since they are just taking raw Strings. It obviously would be a
+performance hit when encoding a lot of small strings, and it isn't trivial to
+implement correctly (you'd have to check the first three string characters, and
+you'd have to be careful to avoid going past the end of the string), although no
+worse than any other string operations.
+
+And of course checking for BOMs would do no good 90% of the time when a part of
+a string is encoded, and it isn't the part with the BOM that's passed. I don't
+think it would catch enough errors to be worth the overhead.
+
+Note that you have similar issues with Decode; you detect invalid sequences, but
+if the given sequence happens to be valid, nothing will be detected (and you'll
+still get the wrong answer).
+
+Anyway, as I previously said, the functions "assume" the encoding expected for
+the parameter. There is no way (in general) for the function to tell if it got
+what it is expecting. If the assumption is violated, they have varying amounts
+of checking -- they'll reject obviously bad contents, but anything else will get
+though.
+
+So back to my proposed wording changes. Are they an improvement (or not); any
+specific suggestions; etc.??
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, October 1, 2011  9:02 AM
+
+> It would be a lot simpler to say:
+>
+>     Returns Item encoded in UTF-8 encoding.
+>
+> (or maybe "Returns the value of Item encoded in UTF-8 encoding.")
+
+Reads ugly, surely "encoded in UTF-8."
+
+is just fine, or perhaps "encoded using UTF-8."
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 11, 2011  9:21 PM
+
+"UTF-8 encoding" is what ISO 10646 defines, so I think we have to say that.
+The first "encoded" could (and should) go, however:
+
+Returns the value of Item represented in UTF-8 encoding.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 11, 2011  9:29 PM
+
+Having said that, I see that the text for Convert and Decode does not include
+the "encoding". That being the case (and adding it to those is awkward), I think
+Robert is right and just dropping the trailing "encoding" is what needs to be
+done.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 11, 2011  10:55 PM
+
+> So back to my proposed wording changes. Are they an improvement (or
+> not); any specific suggestions; etc.??
+
+I didn't get much back on these, and I tweaked them a bit more. Following is the
+Static Semantics part of A.4.11 in !corrigendum format (starting after the reasons
+exceptions are raised) after simplifying the wording. I included the 3 overview
+paragraphs as they cover the important assumptions for the parameter encodings --
+we don't have to mention these in each description.
+
+One could imagine distributing this information to each individual function, but that
+would be a bigger change. The effect of the overview paragraphs is that the actual
+descriptions really only are for specifying the input and/or output encodings.
+
+Complain now or wait until 2017 to make changes...
+
+[Followed by the version /03 of the A.4.11 changes - Editor]
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 12, 2011  5:27 AM
+
+> "UTF-8 encoding" is what ISO 10646 defines, so I think we have to say that.
+> The first "encoded" could (and should) go, however:
+>
+> Returns the value of Item represented in UTF-8 encoding.
+
+that's of course just fine ...
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 12, 2011  5:27 AM
+
+> Having said that, I see that the text for Convert and Decode does not
+> include the "encoding". That being the case (and adding it to those is
+> awkward), I think Robert is right and just dropping the trailing "encoding"
+> is what needs to be done.
+
+I agree this is the better choice
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, October 12, 2011  7:34 AM
+
+Seems fine.  I'll admit I am not focused on this issue...
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, October 12, 2011  9:26 AM
+
+> Complain now or wait until 2017 to make changes...
+
+There should be the following sentence /somewhere/ (i.e. either in the general
+description, or for each appropriate function):
+
+The returned string includes an appropriate BOM if the Output_BOM parameter has
+the value True.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 12, 2011  6:34 PM
+
+There already is such a sentence; it preceeds the list of reasons exceptions are
+raised. (A.4.11(50/3)).
+
+It *is* weird that the general semantics comes after the list of reasons
+exceptions are raised. Perhaps all three of these general paragraphs should be
+earlier in the Static Semantics section?
+
+You can see what I'm talking about in the existing draft of A.4.11 if you
+imagine the two paragraphs that start with "each of the <something>
+functions..." (57/3 and 58/3) getting moved before the "For all Convert and
+<something>" paragraphs (49/3 and 50/3).
+
+Is that a good idea??
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Monday, October 17, 2011  2:05 PM
+
+I'm reading from AI05-0021 rev 1.6 here:
+
+http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0021-1.txt?rev=1.6
+
+!standard A.18.3(102/2)  07-05-17  AI05-0021-1/03
+!standard A.18.2(139/2)
+!standard A.18.3(83/2)
+!standard A.18.4(38/2)
+!standard A.18.7(36/2)
+!standard A.18.2(237/2)
+!standard A.18.3(151/2)
+!class binding interpretation 06-11-10
+!status Amendment 201Z 08-11-26
+!status WG9 Approved 07-06-29
+!status ARG Approved  10-0-1  06-11-18
+!status work item 06-11-10
+!status received 06-08-31
+!priority Medium
+!difficulty Easy
+!qualifier Error
+!subject Issues with containers
+
+
+ From the text of the AI, the !question is:
+
+(1) A.18.3(102/2) says "Equivalent to Delete (Container, First
+(Container), Count)",
+but the second parameter of Delete has mode "in out", and thus cannot be
+passed
+a function call. Should this be fixed? (Yes.)
+
+
+The !wording is:
+
+(1) Replace A.18.3(102/2) with words:
+
+If Container is empty, Constraint_Error is propagated. Otherwise,
+Delete_First
+removes (from Container) Count elements starting at the first element in
+Container
+(or all of the elements if there are fewer than Count elements in
+Container).
+
+
+I think that !wording is wrong.  You should always be able to delete
+items from an empty container, without an exception being raised.
+
+The other problem is that if we are to believe the wording of the AI (it
+applies specifically to the doubly-linked list), then the behavior of
+Delete_First for the doubly-linked list no longer matches the behavior
+for the vector.  That has never been the case, as the vector and list
+were designed to differ only in their time and space complexity, not
+semantics.
+
+The intent of AI05-0021 was to make the specification of the behavior of
+Delete_First more precise, not to change its semantics.  However, the
+wording of the AI really does change the semantics, and not in a benign way.
+
+Here is what I think happened.  We have the original Delete operation:
+
+procedure Delete (Container : in out List;
+                   Position  : in out Cursor;
+                   Count     : in     Count_Type := 1);
+
+We also have the original Delete_First operation:
+
+procedure Delete_First (Container : in out List;
+                         Count     : in     Count_Type := 1);
+
+Delete_First was defined in terms of Delete:
+
+Equivalent to Delete (Container, First (Container), Count).
+
+Yes, the Position parameter of operation Delete has mode in-out, so the
+description of Delete_First is technically incorrect, but we all knew
+what we meant.  However, Pascal wanted to make the description
+technically correct, but the fix ended up breaking things.
+
+Some history, if memory serves me correctly: Way back in the mists of
+time, the Position parameter of operation Delete was allowed to be null
+(by which I mean that the Has_Element predicate function returned
+False).  Late in the design stage, the semantics were changed such that
+if the Position parameter were null, then Delete would raise
+Constraint_Error.  At that time no other changes were made to the
+Delete_First operation.
+
+When the description of Delete_First was changed (per AI05-0021), it was
+a mechanical change, based on the newer semantics of Delete.  But such a
+mechanical replacement doesn't work for Delete_First.
+
+First of all, it should never be an error to delete 0 items from a
+container.  However, using the new semantics described in AI05-0021,
+attempting to delete 0 items from an empty container would raise
+Constraint_Error.
+
+However, there's nothing special about the 0 case.  If Delete_First is
+called with N as the count value, and the list contains M items, then
+for any N >= M, the effect is to clear the container.  It doesn't matter
+that M happens to be 0 (that is, the container is empty).
+
+At a minimum, I think the semantics of Delete_First should be described
+something like this:
+
+"If Container is empty, then the operation does nothing.  Otherwise,
+Delete_First removes (from Container) Count elements starting at the
+first element in Container (or all elements if there are fewer than
+Count elements in Container)."
+
+This at least makes the description of Delete_First internally consistent.
+
+However, I would also make one small change to the semantics of
+operation Delete, to make the behavior of Delete and Delete_First
+consistent with each other: if the Count parameter is 0, then the
+operation does nothing, irrespective of the value of Position parameter,
+and irrespective of the current length of the container.  As it stands
+now, operation Delete raises Constraint_Error if the Position parameter
+is null, even for an empty container.  This seems wrong to
+me, since attempting to delete 0 items from a container should never
+raise an exception.  (When the container is empty, a cursor can only
+have the value No_Element, which is why we should allow this value, at
+least in this one case.)
+
+Note that the index-based Delete operation for the vector container does
+the right thing, and says explicitly that if the Count is 0, then the
+operation does nothing.  The cursor-based version of Delete for vector
+seems to suffer from the same problem as for the list, in which it is
+impossible to request that 0 items be deleted from an empty container.
+I think that when the Count is 0, it should not matter what value the
+Position parameter has, and Delete should be a no-op.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 17, 2011  3:18 PM
+
+> I'm reading from AI05-0021 rev 1.6 here:
+>
+> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0021-1.txt?rev=1
+> .6
+
+Please start with the draft standard first, and only read AIs if you have a need
+to find out why a change was made. (You may have done this, but I can't tell
+from your message.) At this point, AIs don't matter, only the wording of the
+Standard matters (it's rarely the same because of many changes).
+
+Now I do see something interesting here: This AI never made it into the Standard
+at all! None of the changes requested by this AI are in any of the drafts,
+somehow I must have missed it. (Hope there aren't any others like that.)
+
+...
+> At a minimum, I think the semantics of Delete_First should be
+> described something like this:
+>
+> "If Container is empty, then the operation does nothing.
+> Otherwise, Delete_First removes (from Container) Count elements
+> starting at the first element in Container (or all elements if there
+> are fewer than Count elements in Container)."
+>
+> This at least makes the description of Delete_First internally
+> consistent.
+
+Huh? Maybe you mean consistent with Vectors. The wording as given is consistent
+with the Ada 2005 wording for Delete_First for Lists. (Which might have been
+wrong.)
+
+> However, I would also make one small change to the semantics of
+> operation Delete, to make the behavior of Delete and Delete_First
+> consistent with each other: if the Count parameter is 0, then the
+> operation does nothing, irrespective of the value of Position
+> parameter, and irrespective of the current length of the container.
+
+I think this is a bad idea. Passing a null position into an operation that is
+supposed to do something with that position is always a mistake. If you don't
+have a good position, then don't call Delete.
+
+> As it stands now, operation
+> Delete raises Constraint_Error if the Position parameter is null, even
+> for an empty container.
+
+Yes, that makes sense to me. If cursors were instead access types, this would
+clearly have been a null-excluding parameter. There is no reason to ever pass
+null into this routine.
+
+> This seems wrong to me,
+> since attempting to delete 0 items from a container should never raise
+> an exception.  (When the container is empty, a cursor can only have
+> the value No_Element, which is why we should allow this value, at
+> least in this one case.)
+
+That's just too tricky. It doesn't make sense to call Delete of a particular
+element if you don't have any elements. I can see why it might make sense to
+call Delete_First and Delete_Last in that case (because no positions are
+involved), but the specific item Delete is a different beast.
+
+> Note that the index-based Delete operation for the vector container
+> does the right thing, and says explicitly that if the Count is 0, then
+> the operation does nothing.
+
+That seems like a bug to me; if I index into an empty vector, I get
+Constraint_Error. You can't do an element-by-element delete this way. It takes
+great care to do such a delete correctly if you are using slices. Null ranges do
+help some, as numbers (indexes) do work a bit differently than pointers
+(cursors), so I can understand a difference in behavior.
+
+> The cursor-based version of Delete for vector seems to suffer from the
+> same problem as for the list, in which it is impossible to request
+> that 0 items be deleted from an empty container.
+
+It seems right to me. I would never allow passing "null" into a subprogram in a
+similar circumstance, and probably would use a null-excluding parameter to have
+it checked at the call site. One could imagine using a subtype predicate to do a
+similar check in this package (something we might very well have done had they
+existed in Ada 2005).
+
+> I think that when the Count is 0, it should not matter what value the
+> Position parameter has, and Delete should be a no-op.
+
+Yeah, you're always confused about what should happen when Count = 0. :-)
+
+It's clear that this case is really unlikely to occur in practice (you'd have to
+explicitly code it to use a null position, and if you did that, you could have
+just as easily avoided the Delete call in the first place). So the important
+question here is one of compatibility. You are suggesting a silent change in
+behavior which could break existing programs. That seems like a bad idea unless
+the issue is important (and this one [Delete] is clearly not).
+
+Of course, if GNAT is currently doing this "wrong" (that is, doing what you want
+rather than what the Standard says), that would suggest that the change would be
+less of an issue in practice. So, what did the GNAT code do in this case last
+month? (I'm asking about last month so that there is no possibility of gaming
+the answer by making a last-minute change and claiming that's the "current
+behavior".)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 18, 2011  1:18 AM
+
+> > However, I would also make one small change to the semantics of
+> > operation Delete, to make the behavior of Delete and Delete_First
+> > consistent with each other: if the Count parameter is 0, then the
+> > operation does nothing, irrespective of the value of Position
+> > parameter, and irrespective of the current length of the container.
+>
+> I think this is a bad idea. Passing a null position into an operation
+> that is supposed to do something with that position is always a
+> mistake. If you don't have a good position, then don't call Delete.
+
+I was just looking at the mail in AI05-0021-1, and noticed the following from
+Pascal (Sept 29, 2006):
+
+>To me this is just another case where Matt and the rest of us have
+>different views of what exceptions are for.  If you look at the minutes
+>of the 2004 Atlanta meeting, you'll see a very similar discussion
+>regarding the version of Delete that takes a cursor: should it raise an
+>exception or be a no-op if the cursor is null?  Matt wanted a no-op
+>because the post-condition (the element designated by the cursor is no
+>longer in the container) is true.  We decided for C_E on the ground
+>that such a usage pattern was more likely to be a bug, and also because
+>we thought that the post-condition didn't make much sense anyway (what
+>is the element designated by a null cursor anyway?).
+
+This reminds me that we've already had this discussion vis-a-vis Delete, and I'm
+pretty sure that the wording in the Standard is correct.
+
+OTOH, your original query about Delete_First does seem like it is wrong; there
+doesn't seem to be any sensible reason to raise Constraint_Error just because
+the container is empty. There is no problem deleting elements from an empty
+container (it just does nothing). Indeed, all we need to do is drop the first
+sentence and the "otherwise":
+
+"Delete_First removes (from Container) Count elements starting at the first
+element in Container (or all elements if there are fewer than Count elements in
+Container)."
+
+We don't need to mention an empty container, because we are removing all of the
+elements if there are fewer than Count elements: if Count = 0, we remove all
+(which is to say none) of the elements in the container.
+
+Probably a better alternative would be to use the same wording as Delete_Last
+uses (which makes sense because these are next to each other and ought to be
+parallel):
+
+"If Length (Container) <= Count, then Delete_First is equivalent to Clear
+(Container). Otherwise, it removes the first Count nodes from Container."
+
+I've put the above wording into the editorial review AI.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Tuesday, October 18, 2011  10:02 AM
+
+> This reminds me that we've already had this discussion vis-a-vis 
+> Delete, and I'm pretty sure that the wording in the Standard is correct.
+
+Agreed.  I just thought it was odd that Delete_First allows you to delete from
+an empty container, but Delete does not.
+
+> Probably a better alternative would be to use the same wording as
+> Delete_Last uses (which makes sense because these are next to each other and
+> ought to be parallel):
+>
+> "If Length (Container)<= Count, then Delete_First is equivalent to Clear
+> (Container). Otherwise, it removes the first Count nodes from Container."
+>
+> I've put the above wording into the editorial review AI.
+
+OK, thanks for looking into that.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent