From: "Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>
To: comp.lang.ada@ada-france.org
Subject: Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...)
Date: Fri, 24 Oct 2003 01:11:21 +0400 (MSD)
Date: 2003-10-24T01:11:21+04:00 [thread overview]
Message-ID: <mailman.196.1066949253.25614.comp.lang.ada@ada-france.org> (raw)
In-Reply-To: <3F907513.40901@comcast.net>; from "Robert I. Eachus" at Fri, 17 Oct 2003 23:03:01 GMT
Robert I. Eachus wrote:
> Randy Brukardt wrote:
>
> ...
>
> No, actually it wouldn't. It would make a lot of existing code ambiguous.
>
> A : Unbounded_String;
> B : Unbounded_String := A & "something";
>
> Since the string literal could have either type String or Unbounded_String,
> and "&" can have operands of either type, the expression would become
> ambiguous.
>
> Ouch! I forgot about that case when explaining why the non-literal
> conversions would be ambiguous. Having worked on this though, you can
> handle it as you say by a completely new package with different
> overloadings of "&"--which won't happen.
Actually there is no need for completely new package with different overloadings of "&"
- just one little new pragma seems sufficient:
pragma Non_Literal_Argument(subroutine-name, parameter-name);
stating (immediately following the function's spec) that actual argument for
this parameter cannot be a literal. That is, the whole spec for that "&" will be:
function "&" (Left : in Unbounded_String; Right : in String)
return Unbounded_String;
pragma Non_Literal_Argument("&", Right);
and that unhappy ambiguity disappears forever.
Alexander Kopilovitch aek@vib.usr.pu.ru
Saint-Petersburg
Russia
next prev parent reply other threads:[~2003-10-23 21:11 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-02 18:02 U : Unbounded_String := "bla bla bla"; (was: Is the Writing...) amado.alves
2003-10-03 0:05 ` U : Unbounded String : " Alexander Kopilovitch
2003-10-03 20:46 ` Dmitry A. Kazakov
2003-10-03 9:00 ` U : Unbounded_String := " Preben Randhol
2003-10-03 11:17 ` Jeff C,
2003-10-04 2:49 ` Robert I. Eachus
2003-10-06 23:57 ` Alexandre E. Kopilovitch
2003-10-07 8:51 ` Dmitry A. Kazakov
2003-10-08 19:12 ` Alexandre E. Kopilovitch
2003-10-09 8:42 ` Dmitry A. Kazakov
2003-10-10 20:58 ` Alexander Kopilovitch
2003-10-13 8:35 ` Dmitry A. Kazakov
2003-10-13 21:43 ` Alexandre E. Kopilovitch
2003-10-14 8:09 ` Dmitry A. Kazakov
2003-10-16 9:39 ` Alexandre E. Kopilovitch
2003-10-18 10:57 ` Dmitry A. Kazakov
2003-10-08 23:18 ` Robert I. Eachus
2003-10-09 21:35 ` Alexandre E. Kopilovitch
2003-10-10 18:10 ` Robert I. Eachus
2003-10-11 19:43 ` Alexandre E. Kopilovitch
2003-10-12 5:03 ` Robert I. Eachus
2003-10-13 9:07 ` Dmitry A. Kazakov
2003-10-13 14:36 ` Alexandre E. Kopilovitch
2003-10-13 19:46 ` Robert I. Eachus
2003-10-14 1:35 ` Jeffrey Carter
2003-10-14 17:11 ` Alexandre E. Kopilovitch
2003-10-14 20:26 ` Mark A. Biggar
2003-10-14 20:58 ` Robert I. Eachus
2003-10-15 16:59 ` Alexandre E. Kopilovitch
2003-10-15 20:38 ` (see below)
2003-10-16 0:31 ` Alexandre E. Kopilovitch
2003-10-16 2:30 ` (see below)
2003-10-16 13:54 ` Alexandre E. Kopilovitch
2003-10-16 14:11 ` (see below)
2003-10-16 8:01 ` Dmitry A. Kazakov
2003-10-17 20:26 ` Randy Brukardt
2003-10-17 21:39 ` Alexandre E. Kopilovitch
2003-10-17 23:03 ` Robert I. Eachus
2003-10-23 21:11 ` Alexandre E. Kopilovitch [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-10-03 12:00 amado.alves
2003-10-03 15:54 ` Mark A. Biggar
2003-10-03 20:41 ` Dmitry A. Kazakov
2003-10-03 16:12 amado.alves
2003-10-04 12:16 ` Preben Randhol
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox