Version 1.1 of ai12s/ai12-0400-1.txt

Unformatted version of ai12s/ai12-0400-1.txt version 1.1
Other versions for file ai12s/ai12-0400-1.txt

!standard 13.11(21)          20-10-15 AI12-0400-1/01
!standard 13.11.4(21/3)
!standard 13.11.4(31/3)
!class binding interpretation 20-10-15
!status work item 20-10-15
!status received 20-10-01
!priority Low
!difficulty Easy
!qualifier Correction
!subject Ambiguities associated with Vector Append and container aggregates
!summary
We propose to change the name of the routine that appends a vector to be Append_Vector to eliminate a new ambiguity that occurs in Ada 202x due to the overloading of Append now that Ada 202X allow vectors to have aggregates. For similar reasons, we change the name of a vector Insert and a vector Prepend to be Insert_Vector and Prepend_Vector, respectively. Finally we propose to drop the new Append_One routine in favor of having separate two-parameter and three-parameter Append routines, rather than having one with a defaulted Count of 1. We suggest a similar fix to Doubly_Linked_Lists.
We make this a Binding Interpretation to ease transition to Ada 202X. Any parts having to do with the Aggregate aspect only apply to the Ada 202X version of the standard, as this aspect is not defined in prior versions.
!question
Now that vectors can have (container) aggregates, the following call becomes ambiguous:
X : Vector_Of_Rec; begin Append (X, (A => 42, B => 53));
This is because there are two overloadings of Append, one which appends one or more elements to a vector, and one which appends a vector to a vector. Similar ambiguities arise for Insert and Prepend.
Since implementing container aggregates, AdaCore has reported that a surprising amount of customer code and in-house code has bumped into this new ambiguity.
Should we address this new ambiguity somehow? (Yes)
!recommendation
Eliminate the overloading of the vector x vector operations for Append, Insert, and Prepend, by adding the suffix "_Vector" instead of overloading. At the same time, we propose to eliminate the new Append_One routine which was created to match the requirement of the Aggregate aspect for a two-parameter procedure to do appending. We eliminate the need for Append_One by changing the current Append which has three parameters, that last of which is defaulted, to be two separate overloadings, one taking two parameters and one taking three (non-defaulted) parameters. We make a corresponding change to Doubly_Linked_Lists.
We recommend making this a Binding Interpretation to ease transition to Ada 202X. Any parts having to do with the Aggregate aspect only apply to the Ada 202X version of the standard, as this aspect is not defined in prior versions.
!wording
Modify A.18.2(8/5):
...
Add_Unnamed => Append[_One],
...
Modify A.18.2(36/5):
procedure Insert{_Vector} (Container : in out Vector; ...
Modify A.18.2(37/5):
procedure Insert{_Vector} (Container : in out Vector; ...
Modify A.18.2(38/5):
procedure Insert{_Vector} (Container : in out Vector; ...
Modify A.18.2(44/5):
procedure Prepend{_Vector} (Container : in out Vector; ...
Modify A.18.2(46/5):
procedure Append{_Vector} (Container : in out Vector; ...
Modify A.18.2(47/5):
...
Count : in Count_Type [:= 1])
...
Modify A.18.2(58/5):
procedure Append[_One] (Container : in out Vector; ...
Modify A.18.2(79.2/5):
...
Add_Unnamed => Append[_One],
...
Modify A.18.2(150/5):
procedure Insert{_Vector} (Container : in out Vector; ...
Modify A.18.2(151/5):
If Length(New_Item) is 0, then Insert{_Vector} does nothing. Otherwise, it computes the new length NL as the sum of the current length and Length (New_Item); if the value of Last appropriate for length NL would be greater than Index_Type'Last, then Constraint_Error is propagated.
Modify A.18.2(152/2):
If the current vector capacity is less than NL, Reserve_Capacity (Container, NL) is called to increase the vector capacity. Then Insert{_Vector} slides the elements in the range Before .. Last_Index (Container) up by Length(New_Item) positions, and then copies the elements of New_Item to the positions starting at Before. Any exception raised during the copying is propagated.
Modify A.18.2(153/5):
procedure Insert{_Vector} (Container : in out Vector; ...
Modify A.18.2(154/5):
Length(New_Item) is 0, then Insert{_Vector} does nothing. If Before is No_Element, then the call is equivalent to Insert{_Vector} (Container, Last_Index (Container) + 1, New_Item); otherwise, the call is equivalent to Insert{_Vector} (Container, To_Index (Before), New_Item);
Modify A.18.2(155/5):
procedure Insert{_Vector} (Container : in out Vector; ...
Modify A.18.2(156/5):
If Before equals No_Element, then let T be Last_Index (Container) + 1; otherwise, let T be To_Index (Before). Insert{_Vector} (Container, T, New_Item) is called, and then Position is set to To_Cursor (Container, T).
Modify A.18.2(156.a/2):
Discussion: The messy wording is needed because Before is invalidated by Insert{_Vector}, and we don't want Position to be invalid after this call. An implementation probably only needs to copy Before to Position.
Modify A.18.2(168/5):
procedure Prepend{_Vector} (Container : in out Vector; ...
Modify A.18.2(169/2):
Equivalent to Insert{_Vector} (Container, First_Index (Container), New_Item).
Modify A.18.2(172/5):
procedure Append{_Vector} (Container : in out Vector; ...
Modify A.18.2(173/2):
Equivalent to Insert{_Vector} (Container, Last_Index (Container) + 1, New_Item).
Modify A.18.2(174/5):
...
Count : in Count_Type [:= 1])
...
Modify A.18.2(175.1/5):
procedure Append[_One] (Container : in out Vector;
Modify A.18.3(23/5):
...
Count : in Count_Type [:= 1])
...
Add after A.18.3(23/5):
procedure Append (Container : in out Doubly_Linked_Lists; New_Item : in Element_Type) with Pre => (not Tampering_With_Cursors_Prohibited (Container) or else raise Program_Error) and then (Length (Container) <= Count_Type'Last - 1 or else raise Constraint_Error), Post => Length (Container)'Old + 1 = Length (Container);
Equivalent to Append (Container, New_Item, Count => 1);
!discussion
Overloading of element and vector Append turned out to cause trouble once we allowed aggregates for Vectors. We considered various solutions, but ultimately felt that the vector x vector Append was relatively rarely used, so changing its name would be fine.
We recommend that this AI is a Binding Interpretation so vendors may add the Append_Vector / Prepend_Vector / Insert_Vector to the 2012 version of the Vectors generic, to smooth transition to this newer version. Below we suggest that the ACATS test for Ada 2012 shift to using these "_Vector" versions, but not try to ensure that the old versions are removed, as some implementors may choose to keep them for existing customers who do not intend to move to Ada 202X in the near term.
Append_One was added as part of AI12-0212-1 to support the Aggregate aspect requirement for a two-parameter version of Append element, but as part of these naming changes we felt it would be more natural to have two versions of Append element, one taking only two parameters, and one taking a Count parameter, but without a default. This should be upward compatible in all but the most obscure situations. We make a corresponding change to Doubly_Linked_Lists.
!ASIS
No ASIS effect.
!ACATS
We should not force Ada 2012 implementations to remove the old Append vector x vector, even though this AI effectively deletes it. Therefore, the ACATS 2012 test suite should start using Append_Vector, Insert_Vector, and Prepend_Vector to be consistent with this binding interpretation, but not test whether the older versions remain part of the generic package.
!appendix

From: Tucker Taft
Sent: Thursday, October 1, 2020  8:55 PM

We have more customers reporting incompatibilities with Vectors.Append, and
we are also seeing more in our own code, due to the fact that Vectors.Append
is overloaded on a version that appends an element with a version that 
appends a vector.  The Append_One routine avoids that ambiguity, but is only
present in Ada 202X versions of Containers.Vectors.  Here is an example of 
the new ambiguity:

   Append (Rec_Vec, (X, Y, Z => 3));

where Rec-Vec is a vector of records, and "(X, Y, Z => 3)" is an aggregate 
appropriate to the record type.  The problem is that there is an overloading 
of Append that takes two vectors, and with the new container aggregates which 
are supported on vectors, the above could be interpreted as an attempt to 
append another vector onto Rec_Vec.  To avoid the ambiguity, all calls on 
Append like the one above either need to be changed to use Append_One (which 
is not overloaded), or to use a qualified expression, such as:

   Append (Rec_Vec, Elem_Type'(X, Y, Z => 3));

This is straightforward, and works for both Ada 2012 and Ada 202X, but is a 
pain when it occurs all over the place, and makes all such occurrences 
wordier, and potentially requires splitting onto two lines to avoid overlong 
lines.

One solution is to say that container aggregates only allow the use of "[...]" 
notation, so the existing call cannot possibly be a use of a container 
aggregate as the second parameter.  This would mean that no existing Ada 2012 
code would be affected.  However, it goes against our original decision to 
allow "(...)" for container aggregates in addition to "[...]".  I don't know 
how wedded to that decision we feel now, in the face of this growing number of 
instances of incompatibility, and this incompatibility is showing up even 
though a small number of programs have tried to use Ada 202X.

An alternative suggested by Bob Duff is to rename the overloading of Append 
that takes two vectors to be called "Append_Vector" (say).  This would cause 
anyone who was using the overloading in their Ada 2012 code to have to make a 
change when they start using Ada 202X (we could certainly make it a binding 
interpretation or at least allow the "back porting" of this new subprogram to 
Ada 2012 and earlier versions of Vectors).  The general sense is that the 
Append that takes two vectors is used *much* less than the Append that takes 
a vector and an element, so the number of existing programs that would be 
affected would be far fewer.

My view is that we should probably make one or the other of these changes, 
since this is turning out to be an annoying barrier to adoption of Ada 202X.

****************************************************************

From: Richard Wai
Sent: Thursday, October 1, 2020  10:42 PM

> One solution is to say that container aggregates only allow the use of "[...]"
> notation, so the existing call cannot possibly be a use of a container 
> aggregate as the second parameter.  This would mean that no existing Ada
> 2012 code would be affected.  However, it goes against our original decision
> to allow "(...)" for container aggregates in addition to "[...]".  I don't
> know how wedded to that decision we feel now, in the face of this growing 
> number of instances of incompatibility, and this incompatibility is showing 
> up even though a small number of programs have tried to use Ada 202X.

This is the most responsible approach, in my opinion. I don't see how allowing 
(...) as a container aggregate is anything more than a convenience feature. 
While it would have been nice to extend aggregates more generally to container 
types, it is clearly not an option, as explained in 16.a/5. It really ought to 
be one or the other. Clearly the only real reason for (...) to be allowed for 
container aggregates is to blur the line between vectors and arrays, which 
might be unwise. Correspondingly, I'm not a fan of allowing arrays to be 
specified with what appears to be a container aggregate. The whole thing seems 
to be philosophically contrary to strong typing - arrays are not vectors!

I see this as a good opportunity to rein-in on something that was probably 
over-done.

****************************************************************

From: Randy Brukardt
Sent: Thursday, October 1, 2020  11:06 PM

...
> The whole thing seems to be philosophically contrary to strong typing 
> - arrays are not vectors!

I disagree with this last part rather strongly. Arrays and vectors implement 
the same basic abstraction, with the only significant difference being the 
implementation of memory management. There are some other differences which 
mainly exist for historical reasons: a new language would give these things 
exactly the same interface and capabilities.

Ergo, the syntax of these two constructs (one built-in for historical reasons, 
and one not) should be as similar as possible.

> I see this as a good opportunity to rein-in on something that was 
> probably over-done.

I see this as destroying much of the advantage of allowing aggregates in the 
first place. If the syntax is different for constructs with essentially the 
same purpose, you're making the language that much harder to use.

I also don't see this "solution" as buying much, as new Ada 202x code would 
probably use [] for aggregates consistently, in which case the problem would
reappear. Maybe not as annoying as an incompatibility, but still a constant 
annoyance. We have to allow [] for arrays in order to solve the long-standing
null array problem. I don't think anyone is suggesting eliminating that.

Tucker wrote:
> An alternative suggested by Bob Duff is to rename the overloading of Append 
> that takes two vectors to be called "Append_Vector" (say).  

As I've mentioned repeatedly, this issue also infects Insert and Prepend. We 
would need to do the same with them, even if the problem occurs less often 
with them -- otherwise we would have a confusing mess of naming and conflicts.
(Of course, no fix is possible for "&" since no alternative name is possible; 
as previously noted, this already happens for arrays so having conflicts for 
"&" makes them more similar.)

The problem with this idea is that it is a straight incompatibility: any 
existing code using Append and Insert for a vector will fail. OTOH, it makes 
more sense anyway, given that too much overloading is a common Ada design 
mistake. So I'm not sure how I feel about this - but if the *only* choices are 
the two given by Tucker, I much prefer the latter (eliminate the problematic 
overloadings).

****************************************************************

From: Tullio Vardanega
Sent: Friday, October 2, 2020  1:36 AM

I also feel that the overloading can be dropped here, as the feedback so far 
shows it only seems to have aesthetic value and much negative repercussion.

****************************************************************

From: John Barnes
Sent: Friday, October 2, 2020  8:03 AM

Agreed

Overloading is overdone.

****************************************************************

From: Tucker Taft
Sent: Friday, October 2, 2020  7:51 AM

Can you be a bit more specific, since we have overloading of notation in one 
case, and of names in the other?  I presume by saying "drop the overloading" 
you mean you are in favor of replacing Append (Vec, Vec) with Append_Vector 
(Vec, Vec).  Is that right?  And as Randy suggested, we should make 
corresponding changes to Insert and Prepend.

****************************************************************

From: Tullio Vardanega
Sent: Friday, October 2, 2020  8:33 AM

Yes, Tuck. Your summary -- including the "as Randy suggested" -- is what I 
mean. Apologies for my dry prose.

****************************************************************

From: Tucker Taft
Sent: Friday, October 2, 2020  3:50 PM

To be more specific, I would propose:

For Ada 2012 and earlier, with a binding interpretation, we *add* an 
Append_Vector, Prepend_Vector, and Insert_Vector to the Containers.Vectors
package.

For Ada 202X, we remove the Append(Vector, Vector), Prepend(Vector, Vector), 
and Insert(Vector, *, Vector, *) while retaining the new _Vector versions.

Rationale: This would ensure that Append(X, (A => 1, B => 2)) would not 
become ambiguous due to the addition of container aggregates in Ada 202X, and 
for users of Append(Vector, Vector) they could change to Append_Vector and 
have code that would be compilable with both Ada 202X and earlier versions.

****************************************************************

From: Arnaud Charlet
Sent: Saturday, October 3, 2020  2:47 AM

> For Ada 202X, we remove the Append(Vector, Vector), Prepend(Vector, Vector), 
> and Insert(Vector, *, Vector, *) while retaining the new _Vector versions.

I am against removing Append and co only for Ada 2020: this will make it an 
implementation headache for compilers to support Ada 2012 and 2020 in the same 
toolchain, which is what GNAT does and what users expect.

I am fine with doing the removal also in Ada 2012.

****************************************************************

From: Tucker Taft
Sent: Saturday, October 3, 2020  8:13 AM

I am fine either way, though it is a bit unusual to create this sort of 
incompatibility in older versions of the language.  But I suppose ultimately 
there is really only one version of the standard as far as ISO is concerned, 
and the management of old versions is more an issue for vendors than for the 
standards body.  So if AdaCore chose to eliminate the Append(Vector, Vector) 
from their Ada 2012 versions, that would seem to be their choice.  From the 
ARG point of view, what I am suggesting is that adding Append_Vector would 
be a "binding interpretation" and dropping the old Append(Vector, Vector) 
would be part of the Ada 202X revision.

****************************************************************

From: Bob Duff
Sent: Saturday, October 3, 2020  9:30 AM

> I disagree with this last part rather strongly. Arrays and vectors 
> implement the same basic abstraction, with the only significant 
> difference being the implementation of memory management. There are 
> some other differences which mainly exist for historical reasons: a 
> new language would give these things exactly the same interface and 
> capabilities.
> 
> Ergo, the syntax of these two constructs (one built-in for historical 
> reasons, and one not) should be as similar as possible.

I agree with Randy here.  Not only are arrays and vectors almost the same 
thing, but disallowing empty and singleton aggregates does nothing to 
improve type checking.

> As I've mentioned repeatedly, this issue also infects Insert and 
> Prepend. We would need to do the same with them, ...

We don't "need" to.  We can fix these if you like.  I don't care, because 
nobody uses these things -- they tend to lead to quadratic algorithms, for
one thing.

>...even if the problem occurs less often  with them -- otherwise we 
>would have a confusing mess of naming and  conflicts. (Of course, no 
>fix is possible for "&" since no alternative name  is possible; as 
>previously noted, this already happens for arrays so having  conflicts 
>for "&" makes them more similar.)

Nobody uses "&" either, nor the Count parameters of Append.

> The problem with this idea is that it is a straight incompatibility:

Not sure what "straight" means, but what matters is the amount of code that 
has to change.  The existing situation requires more code to change than if 
we rename one Append to Append_Vector.

>...any
> existing code using Append and Insert for a vector will fail. OTOH, it 
>makes  more sense anyway, given that too much overloading is a common 
>Ada design  mistake. So I'm not sure how I feel about this - but if the 
>*only* choices are the two given by Tucker, I much prefer the latter 
>(eliminate the problematic overloadings).

I agree Insert_Vector and Prepend_Vector would be more uniform.
Shrug.  But Append_One is really ugly!

Here's some data:

I ran one of AdaCore's test suites with a modified Ada.Containers.Vectors.
I added a print-out for everything I claimed "nobody uses" above.  Insert 
(there are 8 of them), Prepend (there are 2 of them), and "&" (there are 4
of them).  Also Append of vector, and Append of element with Count /= 1.  
So the "actual output vs. expected" diff will cause the test to fail if 
those are called.

This isn't our entire set of test suites, but it's fairly large (17733 tests, 
mostly coming from customer code, some quite large).

If I ignore tests written specifically to test these features, so I'm only 
counting real code, I get:

    - 1 test has 3 calls to Insert (two versions -- the other 6 are
      never called).

    - No test calls any Prepend.

    - No test calls any "&".

    - No test calls Append of vec,vec directly, although 1 test calls
      Assign, and the implementation fo Assign calls that Append.

    - No test calls Append of element with Count /= 1.

Now a different version of Ada.Containers.Vectors, which contains just one 
print-out, for Append of element, and only if Count = 1.

    11 tests contain 130 such calls.

****************************************************************

From: Brad Moore
Sent: Saturday, October 3, 2020  10:33 PM

> I agree with Randy here.  Not only are arrays and vectors almost the 
> same thing, but disallowing empty and singleton aggregates does 
> nothing to improve type checking.

I agree also, in fact I think beyond Ada202x we should consider making vectors 
even more like arrays. Specifically, with regard to slices, I'd like to see 
routines added to obtain a slice of a vector, and to replace a slice of a 
vector. Unlike arrays, the slice being replaced would not necessarily need to 
be the same size as source slice. Ideally, range syntax for slicing could also
be supported. This sort of slicing operations can be done in languages like 
Python, and its something I think would get used quite a bit.

e.g.

  V (2 .. 3) := "Yippee!";

But I digress. ;-)

> Nobody uses "&" either, nor the Count parameters of Append.

> I agree Insert_Vector and Prepend_Vector would be more uniform.
> Shrug.  But Append_One is really ugly!

If we are considering a backwards compatibility fix to break the overloading 
of Append for vector concatenation,then why don't we consider going all the 
way and also fix the related problem of the ugliness of Append_One by 
eliminating the Count parameter to Append?
Then we could eliminate Append_One, as that would then be what Append does.

I'm not surprised that nobody uses the Count parameter of Append. - It 
certainly isn't something I've ever considering using, and I do make quite 
a lot of use of Append for appending a single element. Basically, I think the 
Count parameter was a mistake, or if it is indeed needed functionality, we 
could add an Append_Multiple, which seems a lot cleaner to me.

****************************************************************

From: Randy Brukardt
Sent: Sunday, October 4, 2020  12:05 AM

> > I agree Insert_Vector and Prepend_Vector would be more uniform.
> > Shrug.  But Append_One is really ugly!
> 
> If we are considering a backwards compatibility fix to break the 
> overloading of Append for vector concatenation,then why don't we 
> consider going all the way and also fix the related problem of the 
> ugliness of Append_One by eliminating the Count parameter to Append?
> Then we could eliminate Append_One, as that would then be what Append 
> does.

Humm. That would require extending the incompatibility to Lists as well. As 
it stands, only Vectors has a compatibility problem (with aggregates), so a 
change to Lists would simply be introducing an incompatibility without any 
reduction in other problems.

We could eliminate Append_One by simply changing to an overloading model for
Append:

     procedure Append (Container : in out Vector; Element : in Element_Type);
     procedure Append (Container : in out Vector; Element : in Element_Type;
                       Count : in Count_Type);

That's probably incompatible in some weird case (there is a profile change of 
course), but all of the usual uses would work the same (even renaming and 
'Access, since the three parameter version would still exist with the original 
subtype profile, only the default would be gone).

I think one of the reasons for Append_One was to work around the aggregate 
problem, but if that is fixed another way, there's no reason for it.

> I'm not surprised that nobody uses the Count parameter of Append. - It 
> certainly isn't something I've ever considering using, and I do make 
> quite a lot of use of Append for appending a single element. 
> Basically, I think the Count parameter was a mistake, or if it is 
> indeed needed functionality, we could add an Append_Multiple, which 
> seems a lot cleaner to me.

I'd definitely be against removing functionality, even if it isn't used much, 
because someone certainly has a use for it. Don't see much point in making 
pain unnecessarily. I'd suggest using overloading to get rid of Append_One.

****************************************************************

From: Bob Duff
Sent: Sunday, October 4, 2020  5:39 AM

> We could eliminate Append_One by simply changing to an overloading 
> model for
> Append:
> 
>      procedure Append (Container : in out Vector; Element : in Element_Type);
>      procedure Append (Container : in out Vector; Element : in Element_Type;
> 
>                        Count : in Count_Type);

I don't understand what that would accomplish. I don't see how it helps 
eliminate Append_One.

> I think one of the reasons for Append_One was to work around the 
> aggregate problem, but if that is fixed another way, there's no reason for it.

Right.  We can eliminate Append_One with or without the above Count change.

****************************************************************

From: Bob Duff
Sent: Sunday, October 4, 2020  5:39 AM

> If we are considering a backwards compatibility fix to break the 
> overloading of Append for vector concatenation,then why don't we 
> consider going all the way and also fix the related problem of the 
> ugliness of Append_One by eliminating the Count parameter to Append?

I don't understand what eliminating the Count parameter would accomplish. It 
doesn't remove the ambiguity of passing an aggregate to Append. Changing the 
name of one Append to Append_Vector does remove that ambiguity.

Then we can remove Append_One, which was added because of that ambiguity.  
But it doesn't solve it, and if I have to change my code anyway, I think I'd 
rather use a qualified expression.

****************************************************************

From: Tucker Taft
Sent: Sunday, October 4, 2020  8:43 AM

Append_One wasn't added to resolve ambiguity.  It was added to fulfill the 
requirements of the Add_Unnamed component of the Aggregate aspect, which 
requires a procedure that has exactly two parameters -- RM 4.3.5(7/5):

"The procedure_name specified for Add_Unnamed for an Aggregate aspect shall 
denote a procedure that has two parameters, the first an in out parameter of 
the container type, and the second an in parameter of some nonlimited type, 
called the element type of the container type."

So using overloading rather than a separately named procedure would match the 
profile required by Add_Unnamed, while still providing a routine that takes 
a Count.

Another solution is to allow the Add_Unnamed procedure to have more than two 
parameters, so long as they all have defaults.  That was mentioned earlier by 
someone, but it does make the whole aspect analysis problem harder, and 
potentially more fragile in the face of maintenance, which seemed undesirable. 

****************************************************************

From: Bob Duff
Sent: Sunday, October 4, 2020  9:01 AM

> Append_One wasn't added to resolve ambiguity.  It was added to fulfill 
> the requirements of the Add_Unnamed component of the Aggregate aspect, 
> which requires a procedure that has exactly two parameters -- RM
> 4.3.5(7/5):

Ah, thanks for the explanation.

> So using overloading rather than a separately named procedure would 
> match the profile required by Add_Unnamed, while still providing a 
> routine that takes a Count.

OK, so maybe that's a good idea.  But it's orthogonal to the idea of changing
the name of one Append to Append_Vector, right?

> Another solution is to allow the Add_Unnamed procedure to have more 
> than two parameters, so long as they all have defaults.  That was 
> mentioned earlier by someone, but it does make the whole aspect 
> analysis problem harder, and potentially more fragile in the face of 
> maintenance, which seemed undesirable.

I've long thought that the semantics of defaulted parameters should look to 
clients as if there were overloadings with all possible combinations of having 
and not having the defaulted formal.  But we're not going to change that, and 
you're probably right that allowing defaults for Add_Unnamed would complicate 
things.

****************************************************************

From: Tucker Taft
Sent: Sunday, October 4, 2020  9:09 AM

>> Append_One wasn't added to resolve ambiguity.  It was added to 
>> fulfill the requirements of the Add_Unnamed component of the 
>> Aggregate aspect, which requires a procedure that has exactly two 
>> parameters -- RM
>> 4.3.5(7/5):
> 
> Ah, thanks for the explanation.

Yes, the discussions were definitely getting muddy!

> 
>> So using overloading rather than a separately named procedure would 
>> match the profile required by Add_Unnamed, while still providing a 
>> routine that takes a Count.
> 
> OK, so maybe that's a good idea.  But it's orthogonal to the idea of 
> changing the name of one Append to Append_Vector, right?

Yes.  Brad brought up the issue of Append_One, but it is orthogonal to the 
issue of container aggregates introducing an overload resolution problem for
Append, though it clearly is related to the container aggregate feature 
overall.
 
>> Another solution is to allow the Add_Unnamed procedure to have more 
>> than two parameters, so long as they all have defaults.  That was 
>> mentioned earlier by someone, but it does make the whole aspect 
>> analysis problem harder, and potentially more fragile in the face of 
>> maintenance, which seemed undesirable.
> 
> I've long thought that the semantics of defaulted parameters should 
> look to clients as if there were overloadings with all possible 
> combinations of having and not having the defaulted formal.  But we're 
> not going to change that, and you're probably right that allowing 
> defaults for Add_Unnamed would complicate things.

The challenge of trying to make such things look identical is that you then 
have to worry about indirect calls, where magically filling in defaults as 
part of an indirect call could create a bit of a mess.

****************************************************************

From: Arnaud Charlet
Sent: Monday, October 5, 2020  2:41 AM

> I am fine either way, though it is a bit unusual to create this sort of 
> incompatibility in older versions of the language.  But I suppose ultimately 
> there is really only one version of the standard as far as ISO is concerned, 
> and the management of old versions is more an issue for vendors than for the 
> standards body.  So if AdaCore chose to eliminate the Append(Vector, Vector) 
> from their Ada 2012 versions, that would seem to be their choice.  From the 
> ARG point of view, what I am suggesting is that adding Append_Vector would 
> be a "binding interpretation" and dropping the old Append(Vector, Vector) 
> would be part of the Ada 202X revision.

As long as we have a gentlemen's agreement that no ACATS 4 test will try to 
call the old Append(Vector, Vector) and co, that's OK I guess.

****************************************************************

From: Tucker Taft
Sent: Monday, October 5, 2020  7:01 AM

Agreed, that would be a good way to allow for this approach.

****************************************************************

From: Jeff Cousins
Sent: Monday, October 5, 2020  1:00 PM

> As long as we have a gentlemen's agreement that no ACATS 4 test will try
> to call the old Append(Vector, Vector) and co, that's OK I guess.

Hi Arno.  Just to clarify, are you proposing to remove the existing ACATS 4 
tests for Append (and &) of a Vector: CXAI001.A, CXAI010.A and CXAIA01.A,  or
that there shouldn’t such tests in ACATS 5 (assuming that’s what the test 
suite for Ada 202X will be called) ?

****************************************************************

From: Tucker Taft
Sent: Monday, October 5, 2020  1:17 PM

I believe the former, since AdaCore wanted the Ada 2012 package to be a pure 
subset of the Ada 202X package, I believe.  There is no reason to remove the 
(sub)test for "&"(vector, vector) though it might need a qualification on the 
aggregate in the Ada 202X test suite.  If we make this change a binding 
interpretation, then the simplest fix is to change the ACATS4 test to use 
Append_Vector instead of Append(Vector, Vector), which should kill two birds 
with one stone, by checking the implementation of the binding interpretation 
and allowing implementors to remove the Append(Vector, Vector) from the Ada 
2012 package if they believe that is a better solution for their customers.

Randy might have a different view!

****************************************************************

From: Randy Brukardt
Sent: Monday, October 5, 2020  2:09 PM

Actually, that's precisely what I was thinking.

****************************************************************

Questions? Ask the ACAA Technical Agent