Date: Sat, 20 Jul 2024 08:14:06 +0100
On Saturday, July 20, 2024, Jason McKesson wrote:
>
> 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.
>
I get what you're saying but I started P3357 out of desperation because of
a lack of progress. 9 out of 10 people want NRVO in C++26 but that just
wasn't going to happen -- P2025 has been stagnating.
I originally conceived P3357 as a stop gap -- almost like 'emergency
legislation' -- with the intention that it would later be made deprecated
by P2025, but now I think P3357 will take its place.
Sebastian and I will have Revision 1 of the paper published probably by the
end of this week.
>
> 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.
>
I get what you're saying but I started P3357 out of desperation because of
a lack of progress. 9 out of 10 people want NRVO in C++26 but that just
wasn't going to happen -- P2025 has been stagnating.
I originally conceived P3357 as a stop gap -- almost like 'emergency
legislation' -- with the intention that it would later be made deprecated
by P2025, but now I think P3357 will take its place.
Sebastian and I will have Revision 1 of the paper published probably by the
end of this week.
Received on 2024-07-20 07:14:09