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

[Dukc]

On Friday, 5 March 2021 at 12:20:36 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review of DIP 1040, "Copying, Moving, and Forwarding".

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.

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.

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

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.

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.