DIP 1014:Hooking D's struct move semantics--Community Review Round 1

[Shachar Shemesh]

On 17/05/18 19:08, Kagamin wrote:
> On Thursday, 17 May 2018 at 13:50:26 UTC, Shachar Shemesh wrote:
>> There is no such use case. Please remember that at the time opPostMove 
>> is called, both new and old memory are still allocated.
> 
> That's an interesting moment too. A struct that was supposed to be moved 
> is copied instead and exists in two places simultaneously. Can't tell it 
> yet, but it can have a hole in type system and opPostMove can only be 
> trusted, not safe.

It is a hole (of sorts) in the type system, in that "old" is not going 
to have a destructor run on its code.

With that said, just because the code is not safe, does not mean it is 
not @safe.

The only inherent non @safe thing we advocate here is if you want to be 
able to move const/immutable structs, in which case DIP 1014 advocates 
casting the constness away. That will, of course, have to be either 
@system or @trusted.

Shachar