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