On Fri, Jul 19, 2024 at 6:36 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 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 C++ standardization process isn't for that. It's not meant to be a
"guess and check" type process, where you put out whatever idea you
want and crowd-source the actual thinking about what the shape of it
needs to be. That's useful to do in general, but that's not what
standardization is for.

If a proposal is still in the brainstorming phase, then it's too early
to be considered for standardization.