On Sat, May 25, 2024 at 1:26 PM Lénárd Szolnoki via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On 25 May 2024 18:08:05 BST, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >> I've never needed RVO nor NRVO with an unmovable-and-uncopyable type.
> >
> >I think that you are perhaps focusing too much on unmovable and uncopiable types. You want to do something to an object before returning it, and still have the benefit of RVO.
> >
> >I don't believe the original introduction of guaranteed RVO in C++17 had that in mind either, it was an optimization (that worked more like a calling convention) that guarantees RVO for all types because that made everything much more efficient.
>
> https://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html
>
> The "Why should copy elision be mandatory?" lists immovable types as the first reason.

Yes, but you missed the key point about "do something to an object
before returning it". Prvalue guaranteed elision only permits
*initialization* of the object, as defined by C++ rules. Once
initialized, you can't do anything with it except return it, lest you
lose the benefits of prvalue elision (because it isn't a prvalue
anymore).

In effect, if you have lvalue guaranteed elision, what you're saying
is ultimately that you want initialization of an object to be more
than just a constructor call/aggregate initialization/whatever. That
is, multi-phase initialization, where calling the constructor isn't
enough for an object to be considered ready for use for some purpose.