Should we have unmovable-and-uncopiable return values at all?   Even if it can be technically solved for certain cases, those classes are not meant to be moved, copied or returned. Better change the interface of std::optional::emplace and/or SomeFunctionThatReturnsMutex(). So that  - SomeFunctionThatReturnsMutex gets a pointer, where to construct its mutex and  - emplace gets a Callable, which creates the mutex at the right moment in time   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 12.09.2023 18:30 Betreff:Re: [std-proposals] Copy-construct, move-construct, and PR-construct An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Mon, Sep 11, 2023 at 2:45 PM Frederick Virchanza Gotham wrote: > > So we already looked at two possibilities: > (1) Mark the conversion operator > (2) Mark the class > > The third possibility would be to have a base class that favours conversion: > >     class Monkey : public std::priority_conversion< std::mutex > Guys we have a very obvious deficit in the C++ programming language here  . . .  we should be able to 'emplace' an unmovable-and-uncopiable return value into an 'std::optional' / 'std::variant' / 'std::any' variable. That is to say we should be able to do:    optional<mutex> om;    om.emplace( SomeFunctionThatReturnsMutex() ); Currently we can't do this, and it's something that needs to change. So can people please give their opinions on which of the 3 proposed solutions is preferable? (1) Mark the conversion operator (2) Mark the class (3) Derive the class from 'std::priority_conversion' -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals