> 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@lists.isocpp.org> 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@lists.isocpp.org>
Gesendet: Di 12.09.2023 18:30
Betreff: Re: [std-proposals] Copy-construct, move-construct, and PR-construct
An: std-proposals@lists.isocpp.org;
CC: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>;
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals