Date: Fri, 29 Aug 2025 11:12:40 +0100
On Fri, 29 Aug 2025 at 10:23, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
> On Fri, 29 Aug 2025 at 09:28, Magnus Fromreide via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello!
>>
>> I am feeling frustrated and feel a need to rant a little bit.
>>
>> <- rant -
>>
>> I have a feeling that many of the flagship features added in more recent
>> revisions of the C++ standard are half baked in that they are missing
>> parts that are necessary to make them useful.
>>
>> As examples of this I would like to put up
>>
>> * std::ranges
>> Here we have an ongoing saga of adding stuff from ranges-v3 that
>> is missing and even a roadmap for the things that someone think
>> are most important to add.
>> Here it feels like the most reasonable course of action is to use
>> ranges-v3 and ignore std::ranges.
>>
>
> They should be compatible, no? You can use both, for when you need
> something missing from the standard.
>
>
>>
>> * std::format
>> Here I tried to use it. I wanted to print a vector of unsigned
>> values as 1.2.3 and failed.
>> I then try to search the intenet for how to do it and finds
>> fmt::join - because obviously this is a reasonable thing to
>> do - but then I find that fmt::join expressly wasn't included
>> when range_formaater was added for some reason.
>> I then succumb to the other advise the internet gives:
>> Ignore std::format and just use fmt.
>>
>
> Or use the couple of 30 or so lines of code to do it which are shown in
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2286r8.html#what-additional-functionality
>
> I disagree with your use of "half-baked". What we have in the standard are
> the parts of the features that were considered fully-baked, and ready to
> standardize. The ranges-v3 and {fmt} libraries have lots of experimental
> and unproven pieces, and not all of them are suitable for standardizations
> yet.
>
> If you want to delay standardizing anything until it's all 100% complete
> and perfect, you'll get *nothing* in the standard. The ranges work we got
> in C++20 was already a big undertaking that took enormous effort from
> several proposal authors, and significant review time from many more
> people. If you want all of ranges-v3, we'd still be waiting for that to
> happen now.
>
The reason it works this way is that we don't have enough time to review
bigger "100% complete and finished" features in the 3 year cycle. If
standardizing all of ranges-v3 at once would take 4 years of work, then it
can't happen for the next revision of C++. And so (unsurprisingly)
proposals that are targeting the next revision get higher priority, because
they're aiming for an earlier deadline. But then the bigger proposal never
gets scheduled, because you can never fit it into any one cycle.
So our process favours smaller proposals that get incrementally improved.
This certainly isn't a perfect approach, but I don't see an obvious way to
improve it without slowing down from releasing a new standard every 3 years.
If you would prefer to wait 5 or 10 years for a new standard so that larger
features have time to bake, then just ignore the latest standard and wait
5-10 years before you start using new features. Which is what you're saying
you do (by using ranges-v3 and {fmt}) but then there's no need to rant
about how bad things are. Just use what you want, and wait for the
standards to catch up with where you want them to be. What does complaining
about it achieve?
>
> Complaining that other people doing lots of work haven't done enough work
> for you seems rather entitled.
>
>
>
>
>
> On Fri, 29 Aug 2025 at 09:28, Magnus Fromreide via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello!
>>
>> I am feeling frustrated and feel a need to rant a little bit.
>>
>> <- rant -
>>
>> I have a feeling that many of the flagship features added in more recent
>> revisions of the C++ standard are half baked in that they are missing
>> parts that are necessary to make them useful.
>>
>> As examples of this I would like to put up
>>
>> * std::ranges
>> Here we have an ongoing saga of adding stuff from ranges-v3 that
>> is missing and even a roadmap for the things that someone think
>> are most important to add.
>> Here it feels like the most reasonable course of action is to use
>> ranges-v3 and ignore std::ranges.
>>
>
> They should be compatible, no? You can use both, for when you need
> something missing from the standard.
>
>
>>
>> * std::format
>> Here I tried to use it. I wanted to print a vector of unsigned
>> values as 1.2.3 and failed.
>> I then try to search the intenet for how to do it and finds
>> fmt::join - because obviously this is a reasonable thing to
>> do - but then I find that fmt::join expressly wasn't included
>> when range_formaater was added for some reason.
>> I then succumb to the other advise the internet gives:
>> Ignore std::format and just use fmt.
>>
>
> Or use the couple of 30 or so lines of code to do it which are shown in
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2286r8.html#what-additional-functionality
>
> I disagree with your use of "half-baked". What we have in the standard are
> the parts of the features that were considered fully-baked, and ready to
> standardize. The ranges-v3 and {fmt} libraries have lots of experimental
> and unproven pieces, and not all of them are suitable for standardizations
> yet.
>
> If you want to delay standardizing anything until it's all 100% complete
> and perfect, you'll get *nothing* in the standard. The ranges work we got
> in C++20 was already a big undertaking that took enormous effort from
> several proposal authors, and significant review time from many more
> people. If you want all of ranges-v3, we'd still be waiting for that to
> happen now.
>
The reason it works this way is that we don't have enough time to review
bigger "100% complete and finished" features in the 3 year cycle. If
standardizing all of ranges-v3 at once would take 4 years of work, then it
can't happen for the next revision of C++. And so (unsurprisingly)
proposals that are targeting the next revision get higher priority, because
they're aiming for an earlier deadline. But then the bigger proposal never
gets scheduled, because you can never fit it into any one cycle.
So our process favours smaller proposals that get incrementally improved.
This certainly isn't a perfect approach, but I don't see an obvious way to
improve it without slowing down from releasing a new standard every 3 years.
If you would prefer to wait 5 or 10 years for a new standard so that larger
features have time to bake, then just ignore the latest standard and wait
5-10 years before you start using new features. Which is what you're saying
you do (by using ranges-v3 and {fmt}) but then there's no need to rant
about how bad things are. Just use what you want, and wait for the
standards to catch up with where you want them to be. What does complaining
about it achieve?
>
> Complaining that other people doing lots of work haven't done enough work
> for you seems rather entitled.
>
>
>
Received on 2025-08-29 10:12:57