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: 
 buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!reality.xs3.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:45:39 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <mn9unk$uvg$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>
 <xtm95y6tqdo6$.1tfgl96oattey$.dlg@40tude.net>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1436057140 31728 24.196.82.226 (5 Jul 2015 00:45:40 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Sun, 5 Jul 2015 00:45:40 +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: number.nntp.giganews.com comp.lang.ada:193922
Date: 2015-07-04T19:45:39-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:xtm95y6tqdo6$.1tfgl96oattey$.dlg@40tude.net...
> On Sat, 04 Jul 2015 13:02:26 +0200, Jacob Sparre Andersen wrote:
>
>> 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 ...
>
> In my view it is not.
>
> Assignment is a syntax sugar of a primitive operation.
>
> If an operation propagates an exception there is no obligation on mutable
> parameters except than type invariants (and post-conditions bound to the
> exception).
>
> Compare it to a procedure with an in-out parameter.

A procedure with an in-out parameter shouldn't clobber the parameters on an 
exception, either. (Consider what happens for a by-copy parameter, of any 
mode, when an exception is raised.) By-reference parameter passing 
introduces the problem, and one could easily argue that it is the bug in the 
language design (introduced for efficiency), not the difference in 
requirements for assignment.

Also note that no parameter will be partially modified by a procedure unless 
the procedure is actually written to do that. That's under the control of 
the programmer. If the language allowed clobbering part of an object during 
a failed assignment, no recovery would be possible (the object would be 
"abnormal" and could never be used again until it is reinitialized -- that's 
what happens for abort). That would make a lot of things hard to guarantee 
short of using SPARK to prove exception absence.

                     Randy.