[OT] Move semantics in a nutshell

[Richard (Rikki) Andrew Cattermole]

To add to this:

On 09/11/2025 4:44 AM, Timon Gehr wrote:
> 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.

Dmd does do data flow analysis, but its all very limited to a single 
forward pass type stuff, including DIP1000. There is also some VRP and 
at least one other thing.

A single forward pass just means that you do a tree walk on the AST. 
This isn't how a DFA engine is usually written. They'll normally have a 
analysis algorithm that dictates how it is analyzed. For DFA the normal 
group of algorithms are called work list. They are slow, not a good fit 
for D by default.

The single forward pass approach is used in my fast DFA engine which was 
merged last month. You can do an awful lot in such an engine, and will 
gain a lot more capability if it confirms to be good after a release.

> 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).

The flags are used for exceptions handling, its not a new thing.
Backends are very good at optimizing such flags.

> 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++.

Right now only the last copy is promoted to a move, so this whole issue 
really only comes down to manually written moves. Quite frankly those 
can be @system and that removes the entire problem as far as the 
language is concerned.

Overall I don't understand the point of move constructors, its not like 
you can use them to aid ownership transfer systems and as far as I'm 
aware they are the only thing that really benefits from it.