__rvalue and Move Semantics first draft

[kinke]

On Sunday, 10 November 2024 at 17:42:27 UTC, Timon Gehr wrote:
> 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?

We can't without rvalue-ref complications in D, but we could 
definitely special-case move ctors and assignment operators, just 
need to match the C++ mangle. And match the same semantics 
obviously, which is the crux. - We can already interop with the 
main C++ lifetime member functions - regular constructors, copy 
constructors, destructors. It'd IMO be a shame not being able to 
use the original C++ move ctor and assignOp too, having to 
re-implement them in D for a complete binding.