DIP 1016--ref T accepts r-values--Formal Assessment

[Manu]

On Thu, Jan 24, 2019 at 1:05 PM kinke via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> wrote:
>
> On Thursday, 24 January 2019 at 09:04:41 UTC, Nicholas Wilson
> wrote:
> > On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> >> The second problem is the use of := (which the DIP Author
> >> defines as representing "the initial construction, and not a
> >> copy operation as would be expected if this code were written
> >> with an = expression"). This approach shows its deficiencies
> >> in the multiple arguments case; if the first constructor
> >> throws an exception, all remaining values will be destroyed in
> >> the void state as they never have the chance to become
> >> initialized.
> >
> > Although not specified by the DIP, I think this could be easily
> > remedied by saying that the order of construction is the same
> > as if the temporaries were not bound to ref, i.e.
> >
> > ---
> > struct A {~this();} struct B{ ~this();}
> > A a();
> > B b();
> >
> > void f(A a, B b);
> > void g(ref A a, ref B b);
> >
> > f(a(),b());  //(1)
> > g(a(),b()); //(2)
> > ---
> >
> > and a() or b() may throw (and are pure), that (1) and (2)
> > exhibit the same exception/destructor semantics.
>
> Describing this stuff in detail (rewritten expression?!), isn't
> trivial and requires knowledge about how calls and
> construction/destruction of argument expressions works.

Sure, it's not 'trivial', but it is 'simple' in that it's isolated,
and it only affects the part of the DIP that defines the rewrite
semantic. It doesn't lead to "practically a completely differnet DIP"
as was suggested.
Changing the detail of the rewrite such that it has the proper effect
required by the surrounding text and handles exceptions correctly can
probably be done in such a way that not a single line of text requires
any changes.