Version 1.1 of acs/ac-00303.txt

Unformatted version of acs/ac-00303.txt version 1.1
Other versions for file acs/ac-00303.txt

!standard 6.6(5)          18-01-12 AC95-00303/00
!class Amendment 18-01-12
!status received no action 18-01-12
!status received 18-01-05
!subject Restricting overload of concatenation operator
!summary
!appendix

!topic Restricting overload of concatenation operator
!reference Ada 2012 RM6.6(172)
!from Author John-Eric Söderman 18-01-05
!keywords &-operator concatenation container
!discussion
FROM RM4.5.3(119)
The concatenation operators  &  are  predefined for every nonlimited,
one-dimensional array type T with component type C .
They have the following specifications

function "&"(Left : T; Right : T) return T
function "&"(Left : T; Right : C) return T
function "&"(Left : C; Right : T) return T
function "&"(Left : C; Right : C) return T

Extension to RM6.6 to legality rules after 5

{
    The concatenation operators  &  are  predefined for every nonlimited,
    one-dimensional array type T with component type C (from RM4.5.3).
    A container type Y (A sub package of Ada.Containers or a type inherited from a sub
    package of Ada.Containers) with components type C. W stands for
    any type. Overloading of &-operator
    is restricted for types C, T and Y to
    function "&"(Left : C; Right : C) return T (in RM4.5.3)
    function "&"(Left : C; Right : T) return T (in RM4.5.3)
    function "&"(Left : C; Right : W) return T
    function "&"(Left : T; Right : C) return T (in RM4.5.3)
    function "&"(Left : T; Right : T) return T (in RM4.5.3)
    function "&"(Left : T; Right : W) return T
    function "&"(Left : Y; Right : W) return Y
}

By restricting Ada.Containers &-overloading makes it possible to code
<first> & <something> & <something> & <something> & … 
and the result will be of the type of <first>, except if <first> is of
C-type then the result will be an array of C, T-type.
To get as result of Y-type you can code
<empty Y> & <something>
<empty Y> & <something>

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

From: Randy Brukardt
Sent: Friday, January 5, 2017  9:10 PM

He had previously tried to post a much longer version of this message, which
was too big for the list. Perhaps it will help understand his request. Find
it in the Grab-Bag at http://www.ada-auth.org/ai-files/grab_bag/JES-concat.pdf.

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

From: Randy Brukardt
Sent: Friday, January 5, 2017  9:50 PM

>	!topic Restricting overload of concatenation operator
>	!reference Ada 2012 RM6.6(172)
>	!from Author John-Eric Söderman 18-01-05
>	!keywords &-operator concatenation container
>	!discussion

The reason that we (the ARG) always ask for clear problem definitions is so
that we can evaluate both the problem (is it real, or just a misconception)
and the proposed solution (does this really solve the problem, and is there a
better way).

I'm having a hard time figuring out what problem is supposedly being solved
here. The only clue here seems to be in this statement:

> By restricting Ada.Containers &-overloading makes it possible to code 
> <first> & <something> & <something> & <something> & ...
> and the result will be of the type of <first>, except if <first> is of 
> C-type then the result will be an array of C, T-type.

Given the standard rules for predefined "&", this is always true, and it would
help a lot to know why JES thinks it is not true.

I had hoped to get something from the paper, but it seems confused:

> Facts and the standard
> The “&” operator should result in an array type.

Not really. Like any operator, it can result in anything that author wants
it too. I've seen some pretty bizarre uses. Outside of the predefined uses of
4.5.3, ascribing too much semantics to any operator is going to get one into
trouble.

> Here are some not so clear questions
> 1. if left argument is a non-array type and right argument is an array type
> or a container type then the result should be an array type of the left
> argument (and not a container type)

"container type" here makes no sense. The only predefined container that
defines any "&" operators is Vectors. A vector supposed to act as much as
possible like an array, so it defines the same operators as an array would.
If you do have a concatenation of a vector container to its element type, the
result has to be a vector, as no matching array type is available in the
generic. (What else could the result be in general?)

> 2. if left argument is an array type and right argument is of the a array
> type or a container type then the result should be of the same array type as
> the left argument

There are no such "&" defined by the container or anywhere else unless the
container element type is an array type. In which case, returning an object of
the array type would be nonsense (it would collapse many elements into one,
which not what "&" means).

>3. if left argument is a container type and right argument is of the a array
> type or a container type then the result should be of the same container type
> as the left argument

Again, this can't happen unless the element type is of an array type, but here
he has the correct answer. Apparently, his view of "&" isn't communitive??

> 4. the container types are not array types. Because you cannot specify 
> a simple array indexing to a container type (ct.Element(I) is not the same
> as ct(I) )

Well, actually, the Vector container is supposed to be a close to an array as
we can make it. The above is true, but only because ct.Element(I) is a
constant while usually you can assign into ct(I)! Specifically, the
Ada.Containers use the Constant_Indexing/Variable_Indexing aspects to define
user-defined indexing for container types (specifically vectors). Ada 2020 may
even add aggregates for Vector containers! The only array operations not
allowed on a Vector container is slicing.

---

Best I can figure, JES is running into some conflict when he has an array type
and a vector type with the same element/component type and then uses (in a use
clause) both. That hardly seems to be a new problem, in that the same thing
happens if one defines two distinct array types with the same component type
(again, with conflicting use clauses).

The usual answer is to not do that! And incompatibly changing the operators
available would potentially break many existing programs. That requires a
pretty important problem to consider. But it's hard to tell how important the
problem is as he didn't give any example of the problem he wants to solve.

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

Questions? Ask the ACAA Technical Agent