Discussion: Rvalue refs and a Move construtor for D

Manu turkeyman at gmail.com
Thu Sep 5 21:31:59 UTC 2019

On Thu, Sep 5, 2019 at 1:30 PM kinke via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> [...]
> Potential problems:
> * Don't access the moved lvalue anywhere else in the statement.
> * An lvalue moved in an argument expression is destructed twice,
> i.e., 2 times at the same address.
> * Cannot represent C++ functions with rvalue refs (except for
> move ctor and move-assignment operator).
> * Some more, I'm sure. ;)

We lose by-val calling semantics, which are more efficient for small
struct's (most things), and certain classes of wide-registers in
various architectures (impossible to codify the proper rules in the
I have pondered this same line of thinking to try and preserve
simplicity, but I shot it dead very quickly before I allowed it beyond
my brain ;)

You talk about C++ rval references as if they're complex, but they're
really not. They're easily the best part of C++11.
Their design is a great success, and it is very very well thrught
through. Rejecting ideas from C++ just because they're in C++ is a bad
basis for any decision; C++ has a VERY rigorous process for allowing
language changes. Rval references weren't an initial fault in C++
early design, they were a recent language change, and required a
torturous process to find their way in.
I agree that it is language complexity, and if there's a way to avoid
it, we should absolutely seek it out, but don't flatly disregard the
state of the art. If we can't do BETTER than rval references, then we
shouldn't NOT do rval references just because it's what C++ does (very

More information about the Digitalmars-d mailing list