Discussion: Rvalue refs and a Move construtor for D

[Manu]

On Fri, Sep 6, 2019 at 11:00 AM kinke via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Friday, 6 September 2019 at 15:18:24 UTC, Suleyman wrote:
> > On Thursday, 5 September 2019 at 22:57:27 UTC, kinke wrote:
> >> [...]
> >
> > Seems workable. It only affects the case of moving an lvalue to
> > an value parameter. But here are my observations:
> >
> > 1. `move` should always do what `forward` did in your example.
> > It shouldn't touch the lvalue, for simply removing a call to
> > the move constructor, because T.init is not always considered a
> > valid state and resetting to T.init is a "move" operation but
> > an uncontrolled one which leaves the object in an invalid
> > state. Which why making __move behave just like rvalue ref is
> > more sensible like your first attempt did.
>
> The problem here is the extended lifetime of the by-value
> parameter. Example:
>
> T global;
>
> void foo(T param) { /* make T own a huge buffer */ }
>
> void caller()
> {
>      foo(move(global));
>      // without destructing and resetting to T.init, `param`
> continues to live
>      // and keeps the huge buffer alive, until `global` is
> reassigned or destructed
> }
>
> > 2. What you have proposed so far only replaces rvalue ref
> > parameters. You haven't tackled rvalue ref returns. What do you
> > propose as an alternative.
>
> I never thought about that, I don't think I've ever returned an
> rvalue ref in C++. Give me some time to think about it.

There's another case where you can attribute a method with `@rvalue`
to apply to the `this` reference. This should naturally work in D
under the `@rvalue` proposal.

Ie:

struct S
{
  Thing member;
  ref Thing fun() { return member; }
  Thing fun() @rvalue { return move(member); }
}

This can be very valuable, and even more so in D where we use a lot of
UFCS chains.