As someone who writes high-reliability C++ but is completely outside the standards process, I see the issues with C++ Contracts. It isn’t clear that it solves a problem that anyone has in real codebases, especially after C++20 concepts.
If you were already writing high-reliability C++ then the benefits are difficult to quantify. If you weren’t writing high-reliability C++ then it saves you almost nothing over doing the standard idioms of high-reliability C++ that were already available to you at very marginally more cost. It does standardize expression of it in narrow cases but the payoff seems minimal.
Most of what C++ Contracts delivers is a mashup of what you can already do with constexpr and C++20 Concepts. I like reliability features but this feature, as delivered, looks fairly useless if you already use reliability features. A compelling standard would need to make much deeper guarantees out of the box. And the compiler can already see through most compositions of constexpr and C++20 concepts, which is already very expressive.
C++ Contracts looks a bit like a feature that was designed long before current standard features existed.
show comments
LugosFergus
I get why some folks would like to see contracts in the language, but C++ is also buckling due to the shear complexity that's getting tacked on to it. I'd rather see more proposals such as C++26's "erroneous behavior" that attempts to reign in the language's shortcomings.
show comments
skrrtww
Personally I'd like to see C++ chill out on new features and maybe sort out the shitshow that is char8_t and std::filesystem.
show comments
imaginit
> contracts. Put simply, a number of NBs believe that this feature is not yet ready for release.
The ISO National Bodies voted wisely. C++ has had so many ill defined features over the decades and they wanted to avoid yet another one.
I don't have any skin in the game. I've stayed with the C++11 feature set.
jdw64
But I'm curious—why did DIS fail this time with C++26? Weren't feature additions in C++ usually plentiful?
But they say this is the first case where a DIS failed during the standardization consensus process. Why is that?
aldanor
Approval of runtime failures essentially failed at runtime
wahern
Correct me if I'm wrong, because I don't follow C++ very closely, but based on previous discussions on HN, the opposition paper obliquely referenced in the blog post was presumably Bjarne Stroustrup's, who IIRC had already said he would work behind the scenes to make sure the final pro forma vote to standardize C++26 would fail.
show comments
nukanse
C++ should focus into turning SIMD into a higher level language instead of being a giant collection of intrinsics. Avx code is unreadable.
show comments
hankbond
Maybe my reading comprehension has just nosedived but I could not find where this article discusses what the heck Contracts refers to?
show comments
ranger_danger
Maybe this time could be used to consider memory safety much more seriously.
EDIT: Would love to know why people are so angry about that?
show comments
vivzkestrel
- since you are a part of the voting group, i have a doubt
- let us say tomorrow everyone were to consider removing all unsigned variables across c++
- what is the impact in terms of compatibility for all the old c++ applications which i believe would be millions of them if not billions?
- the reason i ask is they say do not unsigned anything as much as you can because overflowing the bottom below 0 is easy
- has there ever been any consideration to get rid of unsigned xyz in c++?
voakbasda
I feel like this is a bellwether event for society at large. Growing impasses between more and more segments of society. Diminishing trust leading to the inability to reach consensus. Maybe it’s just me though.
show comments
SP3269
Time to cancel the project. C++ acquired sufficient set of features over the years, becoming very PL/I-esque.
drivebyhooting
I used to be a C++ programmer but I haven’t done it in a few years.
I pretty much do all my low level vibe coding in Rust. Is C++ still relevant? What prevents Rust from completely supplanting it?
show comments
Animats
At this point, changes to major programming languages have to adapt to a world in which AI systems generate and change much of the code. C++ contracts may be good or bad, but they are from before strong AI coding systems. So it's time to rethink.
And we have no idea what AI systems will be doing in 2027.
As someone who writes high-reliability C++ but is completely outside the standards process, I see the issues with C++ Contracts. It isn’t clear that it solves a problem that anyone has in real codebases, especially after C++20 concepts.
If you were already writing high-reliability C++ then the benefits are difficult to quantify. If you weren’t writing high-reliability C++ then it saves you almost nothing over doing the standard idioms of high-reliability C++ that were already available to you at very marginally more cost. It does standardize expression of it in narrow cases but the payoff seems minimal.
Most of what C++ Contracts delivers is a mashup of what you can already do with constexpr and C++20 Concepts. I like reliability features but this feature, as delivered, looks fairly useless if you already use reliability features. A compelling standard would need to make much deeper guarantees out of the box. And the compiler can already see through most compositions of constexpr and C++20 concepts, which is already very expressive.
C++ Contracts looks a bit like a feature that was designed long before current standard features existed.
I get why some folks would like to see contracts in the language, but C++ is also buckling due to the shear complexity that's getting tacked on to it. I'd rather see more proposals such as C++26's "erroneous behavior" that attempts to reign in the language's shortcomings.
Personally I'd like to see C++ chill out on new features and maybe sort out the shitshow that is char8_t and std::filesystem.
> contracts. Put simply, a number of NBs believe that this feature is not yet ready for release.
The ISO National Bodies voted wisely. C++ has had so many ill defined features over the decades and they wanted to avoid yet another one.
I don't have any skin in the game. I've stayed with the C++11 feature set.
But I'm curious—why did DIS fail this time with C++26? Weren't feature additions in C++ usually plentiful?
But they say this is the first case where a DIS failed during the standardization consensus process. Why is that?
Approval of runtime failures essentially failed at runtime
Correct me if I'm wrong, because I don't follow C++ very closely, but based on previous discussions on HN, the opposition paper obliquely referenced in the blog post was presumably Bjarne Stroustrup's, who IIRC had already said he would work behind the scenes to make sure the final pro forma vote to standardize C++26 would fail.
C++ should focus into turning SIMD into a higher level language instead of being a giant collection of intrinsics. Avx code is unreadable.
Maybe my reading comprehension has just nosedived but I could not find where this article discusses what the heck Contracts refers to?
Maybe this time could be used to consider memory safety much more seriously.
EDIT: Would love to know why people are so angry about that?
- since you are a part of the voting group, i have a doubt
- let us say tomorrow everyone were to consider removing all unsigned variables across c++
- what is the impact in terms of compatibility for all the old c++ applications which i believe would be millions of them if not billions?
- the reason i ask is they say do not unsigned anything as much as you can because overflowing the bottom below 0 is easy
- has there ever been any consideration to get rid of unsigned xyz in c++?
I feel like this is a bellwether event for society at large. Growing impasses between more and more segments of society. Diminishing trust leading to the inability to reach consensus. Maybe it’s just me though.
Time to cancel the project. C++ acquired sufficient set of features over the years, becoming very PL/I-esque.
I used to be a C++ programmer but I haven’t done it in a few years.
I pretty much do all my low level vibe coding in Rust. Is C++ still relevant? What prevents Rust from completely supplanting it?
At this point, changes to major programming languages have to adapt to a world in which AI systems generate and change much of the code. C++ contracts may be good or bad, but they are from before strong AI coding systems. So it's time to rethink.
And we have no idea what AI systems will be doing in 2027.