C++26 Disapproved

thatxliner 190 points 83 comments November 04, 2026
andreasfertig.com · View on Hacker News

Discussion Highlights (20 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?

hankbond

Maybe my reading comprehension has just nosedived but I could not find where this article discusses what the heck Contracts refers to?

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.

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.

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.

SP3269

Time to cancel the project. C++ acquired sufficient set of features over the years, becoming very PL/I-esque.

jandrewrogers

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.

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.

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?

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.

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.

nukanse

C++ should focus into turning SIMD into a higher level language instead of being a giant collection of intrinsics. Avx code is unreadable.

aldanor

Approval of runtime failures essentially failed at runtime

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?

lowatt

> By voting “no,” an established system, one based primarily on trust and respectful collaboration, has been shaken. I don't get it. If ISO deliberately requires two levels of approval, why should exercising the second level's voting authority be considered a betrayal of trust?

Zepto8537

major C++26 features, including reflection, std::execution and library hardening, are also delayed because they were included in the same draft.

nanolith

While I can understand that C++ contracts were met with controversy, contract annotations scoped at analysis time that can be verified by external tools, such as static analyzers, model checkers, or automatic theorem provers, are incredibly useful. I put together an alternative function contract and invariant mechanism in C using CBMC and custom macros that effectively allows me to perform formal methods in C using compositional verification. The reason why I chose C is because of its relative simplicity and relative ease of building tooling around it. C++ contracts provide some feature parity, and would let me take advantage of some of the features in C++ relative to C. I hope that the contract proposal is workshopped and simplified so it can be proposed again for a future version. Its current form is unsuitable, but it deserves a second chance with a simpler implementation. Contracts would narrow the safety gap between C++ and languages such as Ada / SPARK.

thefourthchime

I have no idea why anyone would work in C++ in 2026. If I had to work on an existing codebase, I'd just have Claude rewrite it in Rust. It's always been a miserable, awful mess.

shevy-java

C++ is in a strange position. If you look at "let's use AI to rewrite xyz in Rust", then C++ has to wonder why it isn't as often mentioned compared to Rust here. I am not saying AI should be the future, but merely compare why Rust is cited here more frequently than C++. That's just one of many other things. Rust also got popular due to crates. How is the alternative called in C++? Barely anyone outside the C++ community knows. And that's also a problem. C++ isn't going away anytime soon, of course, but when people keep on mentioning alternatives again and again then it shows that the competition intensifed a lot.

Semantic search powered by Rivestack pgvector
11,510 stories · 108,877 chunks indexed