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

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 10 February 2016 at 20:42:29 UTC, w0rp wrote:
> Back on the original topic, Scott Meyers often says "std::move 
> doesn't move." It's more like std::rvalue_cast. C++ uses 
> r-value references in order to be able to rip the guts out of 
> objects and put them into other objects.

Well. In C++ "std::move(x)" is just a "static_cast<T&&>(x)" for 
"T x".

"T&&" references are different from "T&" by acting like T& 
references when used, but not on overloads. They are primarily 
for distinguishing between overloads on temporaries in function 
calls, T&& binds to temporaries. So you use "std::move(x)" to 
tell the type system that you want it to be cast as a references 
to a temporary like reference (or rvalue reference).

So that's why constructors with "T&&" are called move 
constructors (taking stuff from temporaries) and "const T&" are 
called copy constructors (assuming that the parameter might have 
a long life on it's own).

> That kind of return value optimisation was the original 
> motivation for r-value references, for when C++98 RVO isn't 
> good enough, from my understanding.

It is for overloading. Why allocate lots of stuff by copying it 
if you know that the referenced object is about to die anyway? If 
it is dying we just steal the stuff it is holding.

stack.push(string("hiii")) // we could steal this stuff
string x("hiii")
stack.push(x) // we have to copy this stuff

> Maybe someone else will correct me on a point or two there, but 
> that's the understanding of move semantics in D that I have had.

I don't think D has move semantics... It does copying and 
clearing... The postblit thing looks like a dirty hack to me.