From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5037bf0bb33408c8
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-10-09 05:44:56 PST
Newsgroups: comp.lang.ada
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!world!news
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Subject: Re: "&" for array versus "&" for Strings
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Sender: news@world.std.com (Mr Usenet Himself)
Message-ID: <wccelaz3hq9.fsf@shell01.TheWorld.com>
Date: Wed, 9 Oct 2002 12:43:42 GMT
Content-Type: text/plain; charset=us-ascii
References: <mailman.1034141702.27775.comp.lang.ada@ada.eu.org>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Organization: The World Public Access UNIX, Brookline, MA
Xref: archiver1.google.com comp.lang.ada:29613
Date: 2002-10-09T12:43:42+00:00
List-Id: <comp.lang.ada>

"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