Hi, to get a very general solution for arbitrary containers and arbitrary non-movable objects, there are two ways: 1) Delay the construction of the object so that it is called from within the container -> The construction in-place is handled by a Callable provided to the container and called at the right time 2) The emplace function of the containers (and the identity of the container) are put into a Callable with a standard interface and provided to 'some_func()' 1) would need an extension of the standard library interface for the container types including std::optional<T> so that emplace could also take a Callable. That Callable would have a pointer to the memory dedicated for construction as first parameter and would do a placement new. 2) can be implemented in user code. One could define a concept for emplace-Callables or perhaps create some utility functions to make the usage easier. The callable solutions would be more powerful/general than improved copy/move elision, but perhaps the performance is worse? Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 08.09.2023 00:57 Betreff:Re: [std-proposals] Copy-construct, move-construct, and PR-construct An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; 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. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals