Feedback Thread: DIP 1040--Copying, Moving, and Forwarding--Community Review Round 1

[Walter Bright]

On 3/16/2021 10:19 AM, Dukc wrote:
> It is labourous for the reader to get the difference between move and copy 
> constructors, which is that copy constructors have a `ref` parameter. It'd be 
> easier if this was explicitly mentioned.

There'll be some more text added to deal with Rvalue Constructors, that should 
take care of this.

> I don't like the term "move assignment operator". The operator is the same 
> assignment operator we already have, no need to rename it. Just talk about how 
> identity assignments are handled when the argument can be moved. You can call 
> that a move assignment, but leave the trailing "operator" out, since there's no 
> new operator.

It's good to distinguish between a move and a copy.


> There's no discussion how a move constructor will interact with a possible 
> `opPostMove` in a struct or one of it's fields (DIP1014).

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1014.md

Although #DIP1014 was approved, this DIP replaces it. That should be covered in 
the text.


> As for all the stuff about EMOs, I don't like that at all. We already allow the 
> compiler to move a struct instead of copying it, if it can detect a last use. 
> And also we have the possibility to manually elide copying via 
> `std.algorithm.move`. If I recall TDPL book correctly, returning a value or 
> passing a Rvalue to a function is already guaranteed to move. And those rules 
> are for all structs, not just for those that have some fancy operator overloads.
> 
> I also don't like all the rules about detecting last uses. Those are 
> optimizations, not something the language spec should complicate itself for.
> 
> There is a breaking change that hasn't been mentioned. An identity assignment 
> with no `ref` for the argument, or an `auto ref` argument, is going to become a 
> move assignment. Thus it will break if it throws something.

Only if the move assignment is defined, so it shouldn't be breaking.

> All in all, I like the idea of move constructor - it is the same improvement 
> over `opPostMove` that copy constructors are over postblits. But I cannot say 
> the same about rest of the DIP.