On Fri, Jul 19, 2024 at 11:00 PM Tiago Freire wrote:
>
> That wouldn't be the way that I would have put it.
> One of the properties that is sought after in a proposal is to be on solid ground.
> Once it's accepted it is going to be supported hopefully indefinitely. There's no
> room for "oops, yeah maybe we should change it and do it this way instead".
>
> The fact that it is constantly changing, and that you can't pin down the basic
> question of "what is this even supposed to do", should be a red flag.


We want to achieve all the things that can be achieved by Named Return
Value Optimisation. Specifically we want to construct an object,
perform some post-constructional operations on said object, and then
return said object by value from a function -- all without a copying
or moving said object. This would allow us to return a locked mutex by
value from a function.


> For something that is supposed to be a stop gap until Anton's paper is eventually
> accepted, and when it does this feature becomes immediately useless... you can
> do the math.


I don't see the problem in an idea changing five thousand times before
the final solution is settled upon.

The next revision of P3357 won't have self-deprecating wording to say
that P2505 is superior. In fact, polls show that P2025 isn't what
programmers want. Programmers want NRVO in some form, but they don't
want P2025.

By the way . . . for the people who want access to the return slot,
for a much more low-level way of doing NRVO, check out these two
papers:

    http://www.virjacode.com/papers/paper_nrvo_latest.pdf
    http://www.virjacode.com/papers/returnslot.htm