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

[RazvanN]

On Monday, 8 March 2021 at 10:38:25 UTC, Walter Bright wrote:
> On 3/8/2021 12:23 AM, RazvanN wrote:
>> On Friday, 5 March 2021 at 12:19:54 UTC, Mike Parker wrote:
>>>

>> Moreover, what happens in this case if we have a struct that's 
>> not an EMO, but defines a move constructor?
>
> That means it does not have a Move Assignment Operator. It 
> doesn't get EMO semantics. The Move Constructor section applies.
>
Even if the move assignment operator is implicitly generated? The 
DIP states: "If a Move Assignment Operator is not defined for a 
struct that has a Move constructor, a default Move Assignment 
Operator is defined and implemented as a move for each of its 
fields, in lexical order."

Is it possible to have a non-EMO struct that defines solely a 
move constructor or solely a move assignment operator? It seems 
like if you define one, you implicitly get the other one.
>
>> 2. What are the situations where a move constructor call is 
>> implicitly inserted by compiler? This is not explicitly stated 
>> in the DIP and it is rather confusing.
>
> It's in the Move Constructor section.
>
>
>> For example, when an instance is passed by `move ref` is there 
>> a move constructor call?
>
> No, because it is passed by ref.
Ok, correct me if I am wrong, but it seems that if you define a 
move constructor, you implicitly get a move assignment operator 
and viceversa. This means that your struct becomes an EMO if you 
define one or the other. Once you have an EMO struct, besides the 
trivial `S a = b` are there any other situations where the move 
constructor may be called? It seems that EMOs are always passed 
by reference. If that is the case, why bother defining a move 
constructor when it will not get called? If I am mistaken, can 
you please provide a non-trivial example where the move 
constructor gets called? Also, will a move constructor ever get 
called when an argument is passed to a function?
>
>> 3. The DIP should explicitly state what happens when you pass 
>> an rvalue instance of an EMO by ref. How does that interact 
>> with `-preview=rvaluerefparam` ?
>
> With EMOs, there is no need to use the 'ref' annotation. If you 
> do use 'ref', the special EMO semantics do not apply.
>
So I assume you get an error? Also, what happens with `auto ref` 
deduction when called with an EMO.
>
>> 4. The perfect forwarding section is superficially described 
>> and it is hard to assess its correctness and relationship to 
>> the move constructor.
>
> Please be more specific?
Sorry for being un-informative. I will explain in more detail.
The DIP has this example:

ref S fwd(return ref S s) { return s; }

void f(S s);
...
S s;
f(fwd(s));
f(fwd(S());

Assuming S is an EMO, when we have `f(fwd(S()))` what happens 
here? Is a reference to the rvalue passed to `fwd` or does the 
move constructor get called?
If we simply call `f(S())`, what happens here? Is `S()` passed by 
move ref or do we have a move constructor call?

The DIP talks about move refs, but the examples only use lvalues. 
Is the move constructor ever called for an rvalue instance of an 
EMO?
>
>> 5. Structs with internal pointers that are moved should be 
>> part of the motivation of the DIP.
>
> Yes.