[OT] Move semantics in a nutshell

[Timon Gehr]

On 11/7/25 20:31, Sergey wrote:
> This is really nice tutor about details of C++ and Rust:
> - strong/weak invariants
> - move semantics
> - shared
> 
> I think D should consider to not repeat C++ "errors"..
> 
> https://www.youtube.com/watch?v=Klq-sNxuP2g

Manu has had a strong preference for caller-side destruction, which 
essentially implies that moved-from locations need to leave behind a 
"husk" to destroy, in general weakening the type's invariant (the 
strawman alternative being to add additional runtime boolean flags to 
the function ABI, with additional branches in the destruction logic).

Walter is reluctant to do flow analysis in the frontend and DIP1000 
relies on lifetimes of stack locations following the stack discipline. 
This similarly prefers the "husk" design.

I am not sure what is Kinke's perspective as he has not commented as 
much about the topic.


Supporting "destructive moves" implies callee-side destruction is more 
natural (which actually happens to be the traditional convention with 
`extern(D)`). However, this then either requires a bit more advanced 
static analysis than what DMD is currently doing, or introducing 
additional runtime boolean flags and branches to the destruction logic 
(though the flags would not have to pass function boundaries).

Personally I think adding implicit additional boolean flags and 
branching is a no-go, so the tradeoff revolves around either adding 
non-trivial logic to the type checker in order to attempt to ensure that 
the old values remain inaccessible, or settling on the "husk" design.

Personally, I expect husks to win and invariants to lose in D, at least 
in the near term. While this C++ issue is then not resolved, Manu's 
design does already avoid the "too many reference types" problem from C++.