niedz., 16 lip 2023 o 02:26 Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Sat, Jul 15, 2023 at 7:58 PM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > We can return a mutex by value from a function as follows:
> >
> > std::mutex Func(void)
> > {
> > return std::mutex();
> > }
> >
> > We can do this even though std::mutex can't be moved nor copied. This
> > is called 'Return Value Optimisation', and it's mandatory for the
> > compiler to elide the move/copy operation.
> >
> > But let's change it a little:
> >
> > std::mutex Func(void)
> > {
> > std::mutex mtx;
> > return mtx;
> > }
> >
> > Now it no longer compiles. What we have here is 'Named Return Value
> > Optimisation'. In this circumstance, the compiler may elide the
> > move/copy operation if it wants to, but still the move/copy
> > constructor must be accessible -- therefore it won't work with an
> > std::mutex.
> >
> > So this begs the question.... Is it at all possible to return a locked
> > mutex by value from a function?
>
> Here's a better question: is that a thing you should want? There are
> good, reasonable reasons to want to be able to return non-moveable

This is a rare case where I agree with Frederick, NVRO for not-movable
types is a useful feature.

Even on main isocpp page ws link to article that touched this:
https://devblogs.microsoft.com/oldnewthing/20230612-00/?p=108329

Overall allowing this will make use of factory idiom a lot easier to do
for not-movable types.

As we allow code lake this:
```
X foo() { return X(); }
```
Compilar already need way to propagate destination address to
given function.

> objects. This is not one of them. Indeed, this is precisely the sort
> of thing that people make objects non-moveable to *prevent* people
> from doing.
>

Besides nobody "moving" here anything, there is nothing to prevent.
Right now I can write code like:
```
int main()
{
    X mutex = foo();
    bar(mutex);
}
```
Now I need to copy `bar` everywhere where I use `foo`.
This is not ergonomic and is similar to the "delayed initialization problem".

With NVRO for not movable types I can easy merge `foo` and `bar`
in one function:
```
X fooBar()
{
    X mutex = foo();
    bar(mutex);
    return mutex;
}

int main()
{
    X mutex = fooBar();
    //not need to bother with `bar` as it was already called.
}
```

It should not be harder to handle this for a compiler
compared to movable types, the only difference is that if
is impossible to do instead of move we get hard error.

> There have been discussions of the right sort of syntax for this
> functionality. P2025 went into some detail on the matter, but it
> hasn't moved forward in a couple of years. From
> https://github.com/cplusplus/papers/issues/756 it seems the committee
> was not impressed by the idea.
>
> I doubt that returning locked mutexes is the kind of example that
> would change their minds.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals