Discussion: Rvalue refs and a Move construtor for D

[Manu]

On Thu, Sep 5, 2019 at 3:25 PM kinke via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Thursday, 5 September 2019 at 21:45:10 UTC, Manu wrote:
> > On Thu, Sep 5, 2019 at 2:40 PM kinke via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >>
> >> On Thursday, 5 September 2019 at 19:38:57 UTC, Suleyman wrote:
> >> > The whole program only calls the destructor for the lvalue,
> >> > and only once. You need a competitive alternative.
> >>
> >> Sry, I haven't focused on that - yes, rvalue refs would be
> >> even faster because of elided destruction + T.init reset. For
> >> hard-core guys wanting to optimize that away, I'd suggest to
> >> just use a regular ref in the function signature and enable
> >> `-preview=rvaluerefparam`. A regular ref (combined with either
> >> pragma(mangle) tricks or some UDA for C++ mangling) could also
> >> be used to represent C++ functions with rvalue refs.
> >
> > Please no. This is a terrible series of sentences >_<
> > `-preview=rvaluerefparam` naturally interacts benefitially with
> > the proposed `@rvalue` attribute. Don't mess with that.
>
> Care to elaborate?

Without that preview, you can't pass an rvalue temporary to a ref at
all, so it's a necessary piece of passing rvalues by references.

> Suleyman's example can be slightly adapted to
> this:
>
> void foo(ref S value, int n = 0)
> {
>      if (n > 32)
>          return;
>
>      foo(value, n + 1);
> }
>
> With `-preview=rvaluerefparam`, we can feed it with an rvalue
> too, and get exactly the same behavior as Suleyman's original
> version, without `@rvalue ref` and the need to move the `value`
> parameter for the recursive call.

If you lose the `@rvalue` attribute, you have no idea that you can
steal the contents of `value`... it's not a move argument, it's just
an lvalue argument by ref.
Inside that function, you must copy, because you can't know what you received.