I'm replying to Jason and Breno below:


On Friday, August 11, 2023, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> This "proposal" is not a proposal. It's just an explanation of some
> playing around with code you've done.
>

 On Friday, August 11, 2023, Breno Guimarães via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I completely misunderstood the proposal.
> I thought you were just proving it's possible
> to be done, thus the compiler should do it.
> But your idea is to propose a function to do
> this as a library feature right?
> In that case, it loses the appeal since I have
> to do transformations manually. If the compiler
> can do it, why should we do it manually?


My paper was just to get people thinking and to get the creative juices
flowing. In my paper I show how the object can be constructed at a given
address, or placed inside an std::optional.

If you don't like how I changed the function's signature and used placement
new, then alternatively there could be language support with nicer syntax
(and automatic handling of destroying the object if an exception is
thrown), perhaps something like:

mutex Func(void)
{
    if ( SomeOtherFunction() )
    {
        [[nrvo]] mutex obj1;
        obj1.lock();
        return obj1;
    }

    [[nrvo]] mutex obj2;
    obj2.lock();
    return obj2;
}

But unrelated to NRVO, the function 'PutRetvalIn' which I describe in my
paper achieves something that isn't currently possible in the language. We
/should/ be able to put a function's return value on the heap or inside a
global std::optional.