Discussion: Rvalue refs and a Move construtor for D
turkeyman at gmail.com
Wed Sep 4 01:00:19 UTC 2019
On Tue, Sep 3, 2019 at 5:35 PM Exil via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Wednesday, 4 September 2019 at 00:16:06 UTC, kinke wrote:
> > On Tuesday, 3 September 2019 at 23:51:43 UTC, Manu wrote:
> >> On Tue, Sep 3, 2019 at 2:45 PM Suleyman via Digitalmars-d
> >> <digitalmars-d at puremagic.com> wrote:
> >>> I'm still demanding a use case for rvalue ref other than for
> >>> move semantics.
> >> That's it; move semantics. That's not a minor thing...
> >> Why?
> > Because just detecting move-construction/-assignment/'argument
> > moval' can get away with special identifiers for
> > constructor/assignment operator or some special @move UDA, as
> > Suleyman has proposed so far, instead of fully extending the
> > language by rvalue refs, with mangling additions and new
> > overload rules etc.
> > It's clear that this would restrict C++ interop, but that's the
> > point - do we want to adopt the C++ approach fully, or keep
> > things simple & tidy at the expense of not being able to
> > represent C++ functions with rvalue refs (except for move
> > constructor and assignment op)?
> How would it work with multi-function passing though? With a
> rvalue reference, you are effectively just passing around a
> reference, until the contents of the value are moved. So you can
> pass it through N functions and it won't ever to do a move/copy.
> Would you effectively be relying on the compiler to optimize out
> the un-necessary moves, or would they be unavoidable, as they
> effectively are now?
Yes, this thing. The excessive memcpy's at every level of the
callstack are a major problem.
More information about the Digitalmars-d