On Tuesday, 5 September 2023 12:53:34 PDT Jason McKesson via Std-Proposals
wrote:
> > Solution: move from the return type to a parameter passed by reference.
>
> Which requires creating a new API. The goal here is to take the
> already existing (and common) idiom of emplacement and allow it to
> work through an indirect call.

Not exactly. You just shift where the emplace() call happens.

Instead of
  opt.emplace(some_func());

You'd do
  some_func(opt);

and that function would do the emplacing.

I get back to the point of why the type was unmovable in the first place: its
address is important. So it seems to me that returning such a type is
antithetical: the fact that you can sometimes do it because of enforced copy-
elision is not a reason to expand on it. The API of the function you're
developing should be clear that the object isn't being moved.

Moreover, passing it as a formal parameter makes chaining clearer. If you try
to return it, then you need to satisfy all conditions in the entire chain, in
a sequence of increasingly less likely situations.

Finally, this makes absolutely no difference ABI-wise. The uninitialised
storage for an unmovable return type is passed as an implicit first parameter
in any ABI.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering