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

[Shachar Shemesh]

On 11/07/18 20:04, Johan Engelen wrote:
> 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).

I don't draw the same conclusions from the text as you.

I'm perfectly fine with specifying that nothing here is mandatory if the 
compiler ensures that *the end effect* is as if it happened.

AFAIK, C++ has a standing order to that effect, and it greatly 
simplifies documenting what you want to do.

> 
> ### "__move_post_blt SHOULD be defined in a manner that is compatible"
> What does "compatible" mean?

"Has the same effect as".

It's a little as if you're complaining about something not being 
explicit in one section, and again about that same thing being explicit 
in the next. Precisely why such standing order would be a good idea.

> Some things should be made more explicit, 
> such as the order of calls for compound structs.

I don't think it makes sense to specify the order, except to say that 
member's opPostMove must be called before the instance's opPostMove 
(which the code already says).

> Why "SHOULD" and not "MUST"?

Precisely for the reason you stated above. So that if you want to do 
something else, you may.

> 
> 
> ### "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.

Yes, I'm sorry. I worded the spec for humans.

I can suggest a recursive definition:

hasElaborateMove for a struct MUST return true iff at least one of the 
following is true:
* The struct has opPostMove defined
* hasElaborateMove returns true for at least one of the struct's members.

I'm fine with this definition, and it resolves your concern, but I think 
it is less readable.

You are free to suggest a better way of phrasing this.

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

I don't think I understand this point. Can you suggest what that list 
might contain?

Thank you,
Shachar