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

[Matt Elkins via Digitalmars-d]

On Tuesday, 9 February 2016 at 13:45:13 UTC, Hara Kenji wrote:
> On Tuesday, 9 February 2016 at 00:25:33 UTC, Matt Elkins wrote:
>> On Thursday, 4 February 2016 at 02:33:06 UTC, Andrei 
>> Alexandrescu wrote:
>>> Got it, thanks. That's a bug in the implementation, no two 
>>> ways about it. No copy should occur there, neither 
>>> theoretically nor practically. Please report it to bugzilla 
>>> at http://issues.dlang.org. Thanks very much! -- Andrei
>>
>> Done (sorry for the delay): 
>> https://issues.dlang.org/show_bug.cgi?id=15662
>
> I've replied to issue 15662.
>
> The point of that issue is, an array concatenation or appending 
> may cause the elements' copy.
> The copy occurrence is determined by the runtime situation, so 
> compiler needs to reject such the operation for the @disable 
> this(this) elements conservatively.
>
> Kenji Hara

Actually, I have a follow-up question about this: when you say 
that an array concatenation may cause the elements' copy, do you 
mean only the element being appended? Or can elements already in 
the array be copied? If the latter, isn't it a problem that my 
workaround for appending non-copyable objects into the array 
compiles?

My workaround is like this (typing directly without testing):

// Foo has opAssign defined for rvalues, but post-blit and 
opAssign for lvalues disabled
Foo[] fooArray;
++fooArray.length;
fooArray[$ - 1] = Foo();