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

Walter Bright newshound2 at digitalmars.com
Mon Mar 8 10:38:25 UTC 2021


On 3/8/2021 12:23 AM, RazvanN wrote:
> 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?

The trouble is determining when the caller allocates the space for local 
variable, as it does with NRVO. Hence the restriction.


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

That means it does not have a Move Assignment Operator. It doesn't get EMO 
semantics. The Move Constructor section applies.


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

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


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

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

Yes.



More information about the Digitalmars-d mailing list