Discussion: Rvalue refs and a Move construtor for D
turkeyman at gmail.com
Thu Sep 5 22:31:41 UTC 2019
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
> void foo(ref S value, int n = 0)
> if (n > 32)
> 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.
More information about the Digitalmars-d