__rvalue and Move Semantics first draft

[Timon Gehr]

On 11/10/24 00:01, Walter Bright wrote:
> On 11/9/2024 9:37 AM, kinke wrote:
>> Oh, there's at least one problem with the `this(T)` move-ctor 
>> signature - C++ interop. C++ doesn't destroy the parameter, because 
>> it's an rvalue-ref. The proposed by-value signature in D however 
>> includes the destruction of the value-parameter as part of the move- 
>> construction. The same applies to move-assignment via `opAssign(T)`. 
>> So after calling a C++ move ctor/assignOp with an `__rvalue(x)` 
>> argument, the rvalue wasn't destructed, and its state is as the C++ 
>> callee left it. Automatically reset-blitting to `T.init` would be 
>> invalid in that case, as the moved-from lvalue might still have stuff 
>> to destruct.
> 
> We could disallow __rvalue arguments for call to C++ functions?

How do you even call a C++ function that accepts an rvalue reference from D?

If `extern(C++) this(T)` magically matches the C++ move constructor, it 
seems that additional magic has to be added to all calls in any case to 
deal with the mismatch.