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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Build-in-place semantics?  (Was: Ada design bug or GNAT bug?)
Date: Sat, 4 Jul 2015 19:40:21 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <mn9udm$utg$1@loke.gir.dk>
References: 
 <yo94phsbcvht$.1bktwe2qoqntt$.dlg@40tude.net><mm58b5$9k0$1@loke.gir.dk>
 <4lrj5zz2u2z.u8x9cf7xzic6.dlg@40tude.net><mm9h84$5n8$1@loke.gir.dk><d4629c07-4005-4bd3-8fa6-85d088fb83c9@googlegroups.com><58f64fa9-7d0b-44dd-870c-77d9afcb82c4@googlegroups.com><mn4jj1$n50$3@loke.gir.dk><4228c0ea-837d-42a0-b2a8-a98d8d30f820@googlegroups.com><mn7jl5$p6l$1@loke.gir.dk>
 <87bnfsfanx.fsf_-_@adaheads.sparre-andersen.dk>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1436056822 31664 24.196.82.226 (5 Jul 2015 00:40:22 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Sun, 5 Jul 2015 00:40:22 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:26614
Date: 2015-07-04T19:40:21-05:00
List-Id: <comp.lang.ada>

Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87bnfsfanx.fsf_-_@adaheads.sparre-andersen.dk...
> Randy Brukardt wrote:
>
>> Probably not, build-in-place semantics isn't practical for all
>> non-limited types (think normal assignment, can't build-in-place
>> because if an exception occurs the original value has to be intact).
>
> A very sensible requirement, but wouldn't it be nice ...
>
> I suppose that compilers are allowed to use build-in-place when
> initialising non-limited objects?  (But that would of course in practice
> mean that you had two different compiled versions of every function.)

Yes, of course. It's not possible to write a program that can tell the 
difference. (Code inspection could tell, of course, but that's considered 
cheating - any code that gives the required semantics should be OK.)

One could avoid the assignment problem by introducing a temporary in just 
such cases, but that's essentially the same as not using build-in-place in 
the first place. One also could arrange to just use build-in-place for types 
that don't have the exception-on-assignment possibility (there are plenty of 
those).

                             Randy.