Date: Sat, 30 Aug 2025 09:52:54 +0200
> On Aug 29, 2025, at 10:28 AM, 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.
I would have expected compile-time programming on this list. constexpr is slowly evolving. Which each proposal more features are added to be allowed at compile-time. It is a big crescendo resulting in reflection in the end. But certainly not the reflection we get with C++26. This is not the end, yet. We will have reached the (primary) end when we can inject tokens (which is scheduled for a later date). The first version of reflection is half-baked.
Even half-baked features usually have a long-term goal. As others have explained it is easier to get smaller (partial) features into a standard on the 3 year cycle than the full big feature. I consider it better to have some small (incomplete) features than not have them at all. And it is also better to get big features incrementally than not get these features at all. C++11 was big and C++20 was big. This is not to say that C++14 and C++17 weren’t useful, but those were “minor” releases. It might be that we need to wait for C++29 to get something truely big again.
Maybe we need better marketing for “major” standard releases with only the features that are complete. I find it hard to keep changing the C++ standard of my work-related code every 3 years. (We are supporting Windows, Linux, and macOS with some backwards-compatibility for older OS versions which also means major maintenance for OSes if we want to change standards. It is a lot for a tiny company.) We are always lagging behind a little bit and I get confused about the features in the different standard versions. I thought std::span is so obvious that it must be an older feature (just like std::string_view) and tried to use it with C++17 (it’s C++23, but there’s an open source version). For my private project I decided to do error handling using std::expected just to find out that this is also C++23 (thanks to Tartan Llama I can use it with C++20). Looks like C++23 is what I’m looking for…
>
> As examples of this I would like to put up
>
> […]
>
> * 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.
The problem with new features is that there is not much out there on the internet to find. It takes a while until all the questions have been asked and answered to be searchable. With such a fast standard cycle we’ll always lag behind with proper solutions on the internet. (Finding good information on std::expected with std::error_code and std::error_condition is hard. I have now figured out how to do it properly and consistently that I should probably be the one sharing it on the internet.)
BTW, I have started embracing the std::format/fmt style over iostreams because of translatable strings. In many projects because of multiple platforms and backwards compatibility I still don’t get std::format (i.e. the appropriate libraries) on all platforms.
>
> * co_routines
> Here we have a framework that was added but is all but impossible
> to use without the thirdparty coro librarary but I see no moves
> towards adding that.
> Nowadays it seems all the work goes into senders/receivers which
> admittedly is a better design but it also seems to not need
> co_routines.
> Was co_routines a dead end?
I don’t think that they are a dead end. I write a lot of Qt code. For example networking is asynchronous. I believe it would be much nicer in a framework like Qt to write linear code in a single slot instead of connecting multiple signals to multiple slots. Coroutines could help with that. I’d still like to experiment with an event loop that supports (maybe even is based on) coroutines. We still need to figure out the techniques of what is necessary to do that. But, without the language support for coroutines nobody would even try to do this. Yes, in the current state coroutines aren’t really useful for the normal programmer. But, they offer new avenues for library builders.
>
> There is much talk about the limited time that is available to the committe,
> but adding half baked things to the standard wastes everyones time - that of
> the committe when adding them it and that of the users when they have to
> discover that it falls short of reasonable expectations.
I fully get your frustration. We should have a subset of the standard that is taught with only fully-baked features that are supported by all major compilers from 2 or 3 years ago. Basically the version of C++ that is technically feasible for those that don’t have enough resources to always stay on the bleeding-edge.
>
> - end rant ->
>
> So, with that out of the system I would like to say that I am impressed with
> many of the new things - Hana is a wizard - and looks forward to them
> but I would like to not get more unfinished things added to the standard.
>
> /MF
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> 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.
I would have expected compile-time programming on this list. constexpr is slowly evolving. Which each proposal more features are added to be allowed at compile-time. It is a big crescendo resulting in reflection in the end. But certainly not the reflection we get with C++26. This is not the end, yet. We will have reached the (primary) end when we can inject tokens (which is scheduled for a later date). The first version of reflection is half-baked.
Even half-baked features usually have a long-term goal. As others have explained it is easier to get smaller (partial) features into a standard on the 3 year cycle than the full big feature. I consider it better to have some small (incomplete) features than not have them at all. And it is also better to get big features incrementally than not get these features at all. C++11 was big and C++20 was big. This is not to say that C++14 and C++17 weren’t useful, but those were “minor” releases. It might be that we need to wait for C++29 to get something truely big again.
Maybe we need better marketing for “major” standard releases with only the features that are complete. I find it hard to keep changing the C++ standard of my work-related code every 3 years. (We are supporting Windows, Linux, and macOS with some backwards-compatibility for older OS versions which also means major maintenance for OSes if we want to change standards. It is a lot for a tiny company.) We are always lagging behind a little bit and I get confused about the features in the different standard versions. I thought std::span is so obvious that it must be an older feature (just like std::string_view) and tried to use it with C++17 (it’s C++23, but there’s an open source version). For my private project I decided to do error handling using std::expected just to find out that this is also C++23 (thanks to Tartan Llama I can use it with C++20). Looks like C++23 is what I’m looking for…
>
> As examples of this I would like to put up
>
> […]
>
> * 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.
The problem with new features is that there is not much out there on the internet to find. It takes a while until all the questions have been asked and answered to be searchable. With such a fast standard cycle we’ll always lag behind with proper solutions on the internet. (Finding good information on std::expected with std::error_code and std::error_condition is hard. I have now figured out how to do it properly and consistently that I should probably be the one sharing it on the internet.)
BTW, I have started embracing the std::format/fmt style over iostreams because of translatable strings. In many projects because of multiple platforms and backwards compatibility I still don’t get std::format (i.e. the appropriate libraries) on all platforms.
>
> * co_routines
> Here we have a framework that was added but is all but impossible
> to use without the thirdparty coro librarary but I see no moves
> towards adding that.
> Nowadays it seems all the work goes into senders/receivers which
> admittedly is a better design but it also seems to not need
> co_routines.
> Was co_routines a dead end?
I don’t think that they are a dead end. I write a lot of Qt code. For example networking is asynchronous. I believe it would be much nicer in a framework like Qt to write linear code in a single slot instead of connecting multiple signals to multiple slots. Coroutines could help with that. I’d still like to experiment with an event loop that supports (maybe even is based on) coroutines. We still need to figure out the techniques of what is necessary to do that. But, without the language support for coroutines nobody would even try to do this. Yes, in the current state coroutines aren’t really useful for the normal programmer. But, they offer new avenues for library builders.
>
> There is much talk about the limited time that is available to the committe,
> but adding half baked things to the standard wastes everyones time - that of
> the committe when adding them it and that of the users when they have to
> discover that it falls short of reasonable expectations.
I fully get your frustration. We should have a subset of the standard that is taught with only fully-baked features that are supported by all major compilers from 2 or 3 years ago. Basically the version of C++ that is technically feasible for those that don’t have enough resources to always stay on the bleeding-edge.
>
> - end rant ->
>
> So, with that out of the system I would like to say that I am impressed with
> many of the new things - Hana is a wizard - and looks forward to them
> but I would like to not get more unfinished things added to the standard.
>
> /MF
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-08-30 07:53:08