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





Reply via email to