DIP 1014--Hooking D's struct move semantics--Final Review

[Johan Engelen]

On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
> DIP 1014, "Hooking D's struct move semantics", is now ready for 
> final review.

after quick read:

(would be much easier to do inline commenting, but it appears 
that's not supported)

### Section "Code emitted by the compiler on move"
Dangerous to talk about what "code is emitted" by the compiler. I 
think this DIP doesn't need that, and semantics is enough. "the 
compiler MUST call " should be reworded, because an _actual_ call 
to the function should not be mandatory, because it would limit 
the optimizer in eliding it or inlining it (note that it will be 
hard to _prevent_ the optimizer from eliding/inlining the call as 
currently specified by the DIP). So this should be reworded such 
that the semantic effect is as if the function is called. Also 
unspecified _when_ the function needs to be called.


### "__move_post_blt SHOULD be defined in a manner that is 
compatible"
What does "compatible" mean? Some things should be made more 
explicit, such as the order of calls for compound structs.
Why "SHOULD" and not "MUST"?


### "This MUST return true iff a struct or any of its members 
have an opPostMove defined."
Doesn't cover struct A containing struct B containing struct C 
with opPostMove. Reword e.g. into: "hasElaborateMove!S MUST 
return true iff `S` has an `opPostMove` defined or if 
hasElaborateMove!X is true for any member of S of type X.


### What is lacking is a clear list of exactly in which cases 
`opPostMove` will be called (needed for user-facing documentation 
of the function).

-Johan