Discussion: Rvalue refs and a Move construtor for D

Manu turkeyman at gmail.com
Wed Sep 4 00:58:44 UTC 2019

On Tue, Sep 3, 2019 at 5:20 PM kinke via Digitalmars-d
<digitalmars-d at puremagic.com> 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)?

Move semantics aren't a feature of the move constructor, they are USED
BY the move constructor.
You can move an argument to any function. Consider a unique_ptr, which
can only move. It would be impossible to pass a unique_ptr to any
other function than the move constructor itself.

More information about the Digitalmars-d mailing list