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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e1bb9627c57b7d5b
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-10-03 13:36:23 PST
Path: 
 archiver1.google.com!news2.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!dialin-145-254-038-072.arcor-ip.NET!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: RE: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...)
Date: Fri, 03 Oct 2003 22:41:17 +0200
Organization: At home
Message-ID: <blkmk1$dhfkm$1@ID-77047.news.uni-berlin.de>
References: <mailman.29.1065182628.25614.comp.lang.ada@ada-france.org>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: dialin-145-254-038-072.arcor-ip.net (145.254.38.72)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Trace: news.uni-berlin.de 1065213378 14204566 145.254.38.72 (16 [77047])
User-Agent: KNode/0.7.2
Xref: archiver1.google.com comp.lang.ada:171
Date: 2003-10-03T22:41:17+02:00
List-Id: <comp.lang.ada>

amado.alves wrote:

> "...we already have implicit conversion in Ada for numeric literals."
> (Jeff)
> 
> I know, and that was the 'precedent' for my proposal. And I'm familiar
> with the 'nightmare' of generalised implicit conversion (in C). But this
> could be tamed in Ada by defining the effect scope of pragma
> Implicit_Conversion to be the immediately enclosing block.
> 
> Or a family of such pragmas for fine control of the effect:
> 
>   Implicit_Conversion_Down_From_Here
>   Implicit_Conversion_Up_To_The_Next_Enclosing_Block
>   Implicit_Conversion_All_Over
> 
> However I am not totally confortable with *pragmas* for this class of
> effect. Is their precedence?

It would be awful. The only way *any* conversion may appear is a definition
of a derived type.

type B is new A with ...; -- This inherits and defines a [view] conversion

Similarly there should be a way to *not* inherit an implementation of A, but
provide all necessary conversions instead.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de