Move construction from !is(T == typeof(this))

[Stanislav Blinov via Digitalmars-d]

On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote:

> struct X {}
>
> struct Y {
>   this(auto ref X x)
>   {
>     static if (__traits(isRef, x))
>     {
>       // x is lvalue, copy construct
>     }
>     else
>     {
>       // x MUST be rvalue(?), move construct
>       // does this pattern require that I invalidate x the same 
> way C++ does such that X's destructor won't clean up or crash?

"Require" is a bit too strict. But yes, if the pattern is to 
assume ownership of x's contents, then you should clear it.

> Is this solid? I have a vague memory of thinking on this once 
> and realising there was some edge case where it was logically 
> flawed, but I can't remember clearly.
>
> Assuming this does work, the next issue is something that 
> mirrors std::move(), is there already such a thing?

We can't truly override move semantics in D. The language went 
"all in" and left little leeway to us users in that regard. 
Interestingly enough, we *can* come close in cases such as the 
code below.

> struct X {}
>
> struct Y {
>   this(ref const X x)
>   {
>     // x is lvalue reference, copy construct
>   }
>   this(X x)
>   {
>     // x is an lvalue... which may be a copy of another lvalue. 
> can't move
> construct :/

Why not? The first overload will be called with an lvalue, i.e:

X x;
Y y1 = x;

The second one will be called in all other cases:

Y y2 = X();
Y y3 = move(x); // move(x) returns X

For second overload, x will be destructed once the ctor returns. 
I don't see any reason why you wouldn't move it's guts out.

> I guess the question in this case is how overload selection may 
> or may not work...
> I didn't test this, but I expect it's an ambiguous call given 
> an lvalue?

There is no ambiguity there as far as I can tell.
Same goes for opAssign, you can have

ref opAssign(ref X x) { /*...*/ } // assign lvalue
ref opAssign(X x) { /*...*/ } assign rvalue

I guess you mean that you don't have source for X. But in that 
case, you won't be able to "move-construct" Y from X in C++ 
either. Nor would the compiler. If you at least know the exact 
memory layout of X, you could hack together a custom move:

this(X x)
{
     auto px = cast(XLayout*)cast(void*)&x;
     // move from px...
}

...but that's neither here nor there. The words "dangerous", 
"non-portable" and UB march with pitchforks right behind that 
pattern ;)