Version 1.3 of ai12s/ai12-0400-1.txt
!standard A.18.2(8/5) 20-10-21 AI12-0400-1/03
!standard A.18.2(36/5)
!standard A.18.2(37/5)
!standard A.18.2(38/5)
!standard A.18.2(44/5)
!standard A.18.2(46/5)
!standard A.18.2(47/5)
!standard A.18.2(58/5)
!standard A.18.2(79.2/5)
!standard A.18.2(150/5)
!standard A.18.2(151/5)
!standard A.18.2(152/5)
!standard A.18.2(153/5)
!standard A.18.2(154/5)
!standard A.18.2(155/5)
!standard A.18.2(156/5)
!standard A.18.2(168/5)
!standard A.18.2(169/5)
!standard A.18.2(172/5)
!standard A.18.2(173/5)
!standard A.18.2(174/5)
!standard A.18.2(175.1/5)
!standard A.18.3(23/5)
!standard A.18.3(23.1/5)
!standard A.18.3(58.2/5)
!standard A.18.3(96/5)
!standard A.18.3(97.1/5)
!class binding interpretation 20-10-15
!status Amendment 1-2012 20-10-21
!status ARG Approved 13-0-0 20-10-21
!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 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, the 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])
...
Modify A.18.3(23.1/5): [From AI12-0391-1]
procedure Append[_One] (Container : in out List;
...
Modify A.18.3(50.2/5):
...
Add_Unnamed => Append[_One],
...
Modify A.18.3(96/5):
...
Count : in Count_Type [:= 1])
...
Modify A.18.3(97.1/5): [From AI12-0391-1]
procedure Append[_One] (Container : in out List;
...
!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 test
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