On Thu, Sep 7, 2023 at 5:57 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

But that now requires `some_func` to know about how the object it
creates is being stored. It needs to know if you're using an
`optional<T>` or a `vector<T>` or something else. And it has to work
with different emplacement APIs, like `emplace_back` vs. `emplace`.

`some_func`'s job is to generate an object, not to know where that
object *lives*. That's `opt.emplace`'s job. Single-responsibility
principle and all.

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

That's the main reason why guaranteed elision was added in the first
place. Literally; it's example #1 in the motivation section of P0135.
You're basically arguing that guaranteed elision was bad actually.