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

--- ai12s/ai12-0005-1.txt	2020/08/28 03:25:50	1.37
+++ ai12s/ai12-0005-1.txt	2020/09/04 03:47:34	1.38
@@ -2114,7 +2114,171 @@
 
 ***************************************************************
 
-Editor's note (July 4, 2020): All of the items above this
+From: Tucker Taft
+Sent: Monday, July 27, 2020  8:24 AM
+
+We mention in RM 4.3 an incompatibility in resolving aggregates due to types 
+with an Aggregate aspect now being considered as well.  We indicate the 
+incompatibility will be rare.  Alas, it turns out the overloaded "Append" 
+procedure in Containers.Vectors creates the exact situation where the 
+incompatibility shows up, because it is overloaded with one version having 
+the Element_Type and one having Vector as its second parameter.  So any use of 
+Append with the second parameter being an aggregate is now ambiguous if the 
+Element_Type is a record or array type (or any type that allows an aggregate).
+The Append_One function (which is new, I believe), can be used to resolve the 
+ambiguity in favor of appending an element. 
+
+Interestingly, this same ambiguity has existed forever with arrays of 
+records/arrays when using the "&" operator.  So now Vectors are even more 
+like arrays! ;-)
+
+In any case, I believe we should remove the claim that this is "rare" in the 
+incompatibility section of RM 4.3, and perhaps mention it elsewhere (e.g. in 
+Vectors and Doubly_Linked_Lists), where we could suggest using Append_One 
+(see below) to resolve the ambiguity in favor of appending an element.
+
+One more serious issue is that the Aggregate aspect in Doubly_Linked_Lists 
+points at the Append procedure for Add_Unnamed, and I think in fact we need 
+to introduce a new procedure Append_One as was done for Vectors, since Append
+actually takes three parameters. [Editor's note: This problem was previously
+raised and is addressed in AI12-0391-1.]
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Monday, July 27, 2020  8:34 AM
+
+> ... The Append_One function (which is new, I believe), can be used to 
+> resolve the ambiguity in favor of appending an element.
+
+Make that, the Append_One *procedure* ...
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, July 28, 2020  12:22 PM
+
+If we think this incompatibility could be a significant burden, we could, at 
+least initially, distinguish the Name Resolution rules for aggregates using 
+"[...]" from those using "(...)".  At some future revision we could consider 
+taking the "hit" to make "(...)" use the same rule.  This might ease 
+transition to Ada 202X.
+
+For what it is worth, this incompatibility (along with the addition of the 
+"Empty" functions in Container packages) has caused some headaches at AdaCore
+over the last week or two.
+
+***************************************************************
+
+From: Arnaud Charlet
+Sent: Wednesday, July 29, 2020  2:45 AM
+
+> If we think this incompatibility could be a significant burden, we could, at 
+> least initially, distinguish the Name Resolution rules for aggregates using 
+> "[...]" from those using "(...)".  At some future revision we could consider
+> taking the "hit" to make "(...)" use the same rule.  This might ease 
+> transition to Ada 202X.
+
+No, I don't think it would be a good idea to go half way there.
+
+> For what it is worth, this incompatibility (along with the addition of the 
+> "Empty" functions in Container packages) has caused some headaches at 
+> AdaCore over the last week or two.
+
+Yes, it did (and still does) although I believe part of it should be 
+alleviated (some Ada 2012 code got impacted that shouldn't have been).
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, September 2, 2020  12:59 AM
+
+> We mention in RM 4.3 an incompatibility in resolving aggregates due to 
+> types with an Aggregate aspect now being considered as well.  We 
+> indicate the incompatibility will be rare.  Alas, it turns out the 
+> overloaded "Append" procedure in Containers.Vectors creates the exact 
+> situation where the incompatibility shows up, because it is overloaded 
+> with one version having the Element_Type and one having Vector as its 
+> second parameter.  So any use of Append with the second parameter 
+> being an aggregate is now ambiguous if the Element_Type is a record or 
+> array type (or any type that allows an aggregate).  The Append_One 
+> function (which is new, I believe), can be used to resolve the 
+> ambiguity in favor of appending an element.
+
+For what it's worth, the same ambiguity could happen for Insert, Prepend, 
+and "&"; all of these take a Vector or an Element as a parameter. But none 
+of these happen to have an Append_One to fix the problem.
+
+> Interestingly, this same ambiguity has existed forever with arrays of 
+> records/arrays when using the "&" operator.  So now Vectors are even 
+> more like arrays! ;-)
+
+Yup.
+ 
+> In any case, I believe we should remove the claim that this is "rare" 
+> in the incompatibility section of RM 4.3, and perhaps mention it 
+> elsewhere (e.g. in Vectors and Doubly_Linked_Lists), where we could 
+> suggest using Append_One (see below) to resolve the ambiguity in favor 
+> of appending an element.
+
+Lists don't have these overloaded operations, so no ambiguity problem occurs 
+for lists. This is solely a problem for vectors. As noted above, the 
+suggestion doesn't help unless you happen to be using Append (rather than 
+Insert or Prepend or "&"), so the suggestion isn't very general. It would be 
+better to simply suggest qualification, but that's already what the 
+incompatibility note says.
+
+I still think the incompatibility is unlikely for most types, but obviously 
+Vectors isn't most types.
+
+So I suggest replacing the last three sentences in the AARM note 4.3(6.l/5):
+
+   This can be incompatible in unlikely cases, where overloading of a container 
+   or private type with a type that was previously allowed in aggregates makes 
+   an existing call ambiguous. (For an example, replace type Lim in the example 
+   given above under Incompatibilities With Ada 95 with a Vector from an instance 
+   of Ada.Containers.Vector. The call of P in that case will be illegal in Ada 
+   202x and legal in Ada 2012.) This can easily be fixed by qualifying the 
+   aggregate with the correct type. 
+
+with:
+
+   This can be incompatible in usually unlikely cases, where overloading of a 
+   container or private type with a type that was previously allowed in 
+   aggregates makes an existing call ambiguous. Unfortunately, Ada.Containers.Vectors
+   has a number of such overloadings for Insert, Append, Prepend, and "&", so
+   the problem may appear for any element type of a Vector that allows aggregates.
+   For instance, if My_Vector is an instance of Ada.Containers.Vectors with an 
+   element type of Not_Lim as defined above, and V is an object of My_Vector.Vector, 
+   then My_Vector.Append (V, (Comp => 123)); will be illegal in Ada 
+   202x and legal in Ada 2012. This can easily be fixed by qualifying the 
+   aggregate with the correct type.  
+
+
+A couple of points about this:
+(1) It makes sense to replace the example by one that is likely to occur.
+(2) It seems necessary to say that the incompatibility is usually unlikely; 
+    otherwise, we'd have no justification for introducing it.
+(3) Mentioning Vectors here explains the type that is known to have a problem, 
+    and the one most likely for a user to run into.
+
+Finally, we probably ought to mention this in A.18.2 as well. So add a new 
+Incompatibility AARM note at the end of A.18.2:
+
+   Vector objects now support aggregates. This introduces a potential incompatibility 
+   for overloaded routines, including the Insert, Append, Prepend, and "&" operations
+   defined in this package. If the Element_Type of the vector is a type that allows
+   aggregates (such as a record type), then calls to the operations above with an
+   aggregate element will become ambiguous in Ada 202x, while they would have been
+   legal in Ada 2012. This can be fixed by qualifying the aggregate with the element 
+   type.  
+
+Since these are all AARM changes, these don't get an AI or otherwise put on 
+the agenda, so don't hold any comments.
+
+***************************************************************
+
+Editor's note (September 2, 2020): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************