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

Shachar Shemesh shachar at weka.io
Thu May 17 13:50:26 UTC 2018


On 17/05/18 16:42, Kagamin wrote:
> Looks like requirement for @nogc @safe has no consequence as the DIP 
> suggests to infer them anyway. On ideological side safety can't be a 
> requirement because it would contradict its purpose of providing 
> guarantee.

I think you are confusing __move_post_blt's implementation (by druntime) 
with opPostMove's implementation by the user.

For the former, these attributes are deducted by the compiler. For the 
later, the user may choose to include them for all of the usual reasons 
for including them, not least of which is that if she does not include 
@nogc, then trying to move a struct's instance from @nogc code will 
cause compilation failure.

 > Especially if the suggested use case is handling of dangling
 > pointers.

There is no such use case. Please remember that at the time opPostMove 
is called, both new and old memory are still allocated.

Shachar


More information about the Digitalmars-d mailing list