Re: "&" for array versus "&" for Strings

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> procedure Array_Test is
> 
>   type Name_Array is array (Positive range <>) of String (1..6);
> 
>   procedure Print_Names (Names : Name_Array) is separate;
> 
> begin
> 
>   Print_Names ("Ada   " & "Babbel");
>   Print_Names (string'("Ada   ") & string'("Babbel"));
> 
> end Array_Test;
> 
> > It seems to me that the "&" should resolve to the
> > (string, string)-->Name_Array one, even without the "String'(...)"
> > qualifications.  Apparently, the older compiler resolved it to the wrong
> > one, and the newer one can't resolve it (which is an improvement, but
> > still a bug).
> > 
> > I'm not surprised that such a bug has never been noticed before.  Most
> > people don't write code that uses "&" to concatenate two Strings to
> > produce something other than String!  First, it's confusing (to humans,
> > I mean, in addition to compilers).  Second, it requires fixed-length
> > strings, which is almost never what you want in an array.
> 
> I think only the first statement is ambiguous since the compiler is not allowed 
> to lookk inside the aggregate to see what is is, a string or an array of 
> strings.

There is no aggregate in this example.

There are two string_literals, and RM-4.2(4) says "...single string
type".  So I think this one should resolve OK.

> With the second statment, it's clear the aggregates are strings, so it can 
> resolve the "&" operator to the correct one returning Name_Array. The one 
> returning String is out because Print_Names does not accept String.

- Bob