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

They are meant to be returned, though. Niall Douglas has a thread in
lib-ext "make_unique() does not support immovable types" talking about a
use case for this for async operation states. The stdexec repo does this,
libunifex does this with functionality we added to support emplacement of
results of arbitrary user functions. It is very valuable to be able to
return an object that can have internal references and return it straight
into a memory location.

Return-into-passed-pointer just breaks control and data flow and doesn't
play well with type inference.

What if I want to store an object based on the immovable return type of a
user passed function that decides to return a mutex as part of its return
value, because it's constructing some lockable async state grouped with its
lock and the function that acquires the lock?

struct Storage {
  optional_type<std::invoke_result<UserFunc>> storage_;
};
...
storage_.emplace(userFunc());

This kind of thing is much clumsier if we can't simply use the return type.
Or alternatively we end up with the cost of a heap allocation.

On Tue, 12 Sept 2023 at 11:16, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>