D's equivalent to C++'s std::move?

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 13 February 2016 at 09:11:06 UTC, Lars T. 
Kyllingstad wrote:
> In my experience, in the vast majority of cases a C++ move 
> operation boils down to a memberwise copy (of value types) or 
> copy-and-reset (of reference types).  With the extra logic and 
> program flow that is sometimes involved in move construction 
> and move assignment, I suspect that a straightforward double 
> memcpy as it is done in D will be almost as performant or 
> moreso most of the time.

No? Not in the libraries I write. A move typically just means 
copying 1-4 64 bit values and setting a single 64 bit value in 
the source. Usually written as an inline function.

Or nothing, in the case where the logic does not end up with a 
move, something which D cannot represent with the same semantic 
distinction.

> Add to that the fact that a lot of programmers out there will 
> implement move construction in terms of move assignment -- 
> which makes it a default construction PLUS move -- and move 
> assignment in terms of swap -- i.e., three moves -- for the 
> sake of DRY.

Huh? Move assignments is no different from move construction, 
except you have to release the existing value if the receiving 
object isn't empty. Constructing an empty resource owner object 
usually just means setting a single field to zero, which is 
inlined and removed if it is followed by an assignment.

>  Personally, I think D's move semantics are actually clearer 
> and easier to get right.

But I don't think D has move semantics. I don't think it makes 
for correctness for resource ownership.

> explain to newbies:  If you use std.move() on something it 
> definitely gets moved.  In C++, if you use std::move() on 
> something it may or may not be moved; it depends on the 
> recipient of the move.

No? With D's std.move() the resource can be destroyed or get into 
an inconsistent state if the caller does it wrong? Or can the 
type system help you?