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