On Tue, Sep 12, 2023 at 12:30 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 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'

... that's not how this works. You don't get to say "don't bother
discussing whether a change is worth it; we have to do *something*."

I mean, you *can* say that, but it's not actually going to get much traction.

Here's the core problem from my perspective. We have a solution to
this, an idiom that works effectively in most cases. It only fails in
the event that the destination type has a converting constructor that
uses an unconstrained template parameter. While this is a genuine
limitation, the status quo still solves things in a lot of cases.

As such, any change (language or library) to fully resolve this has to
get over a certain hurdle: is it *really* worth it to make that change
just to deal with the particular cases of "unmovable-and-uncopiable
return value " whose types are implicitly convertible from an
unconstrained type?

You cannot just take it as a given that the answer to this is "yes".
You have to do something more than just say "it's something that needs
to change". You have to argue *why* it needs to change, why the C++
standard needs to fix this one corner case of a corner case.