Date: Sat, 20 Jul 2024 09:33:07 +0200
On 20/07/2024 09.14, Frederick Virchanza Gotham via Std-Proposals wrote:
>
>
> 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.
If you feel P2025 is the right avenue to pursue, I'd suggest to contact
the author to help make progress. If you can agree with the original
author to hand over the paper to you, then you can continue the P2025
series and just publish a new revision. (You might need help from
Nevin Liber to re-assign authorship in the isocpp.org paper system.)
If not, just clone the paper (with due acknowledgments) and publish
one with a new number.
Status of P2025: https://github.com/cplusplus/papers/issues/756
> 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.
If everybody believes P2025 is the right approach, then I'm strongly
opposed to any intermediate "stop gap", which won't go away again
even if the right approach comes along in a few years.
Jens
>
>
> 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.
If you feel P2025 is the right avenue to pursue, I'd suggest to contact
the author to help make progress. If you can agree with the original
author to hand over the paper to you, then you can continue the P2025
series and just publish a new revision. (You might need help from
Nevin Liber to re-assign authorship in the isocpp.org paper system.)
If not, just clone the paper (with due acknowledgments) and publish
one with a new number.
Status of P2025: https://github.com/cplusplus/papers/issues/756
> 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.
If everybody believes P2025 is the right approach, then I'm strongly
opposed to any intermediate "stop gap", which won't go away again
even if the right approach comes along in a few years.
Jens
Received on 2024-07-20 07:33:11