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

RazvanN razvan.nitu1305 at gmail.com
Mon Mar 8 08:23:55 UTC 2021


On Friday, 5 March 2021 at 12:19:54 UTC, Mike Parker wrote:
>

1. The "Returning an EMO by value" section says:

"
S func()
{
     S s;
     return s;
}

This works exactly as it does currently for non-EMO objects.
"

So this code is allowed to compile. However, in the "Returning an 
EMO by move ref" section we have this code:

"
S func(return S s)
{
     S s2;
     return s2;  // error, can't return local by Move Ref
}
"

Isn't this rather restrictive? I can imagine a scenario where you 
would like to return the parameter if some condition is met or 
return a local otherwise:

S func(return S s)
{
    S s2;
    if (_some_condition)
      return s;
    else
      return s2;
}

Moreover, what happens in this case if we have a struct that's 
not an EMO, but defines a move constructor?

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. For example, when an instance 
is passed by `move ref` is there a move constructor call?

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` ?

4. The perfect forwarding section is superficially described and 
it is hard to assess its correctness and relationship to the move 
constructor.

5. Structs with internal pointers that are moved should be part 
of the motivation of the DIP.

Cheers,
RazvanN


More information about the Digitalmars-d mailing list