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.
C++ concepts evaluate the properties of types at compile-time. You can inject arbitrary constraints on type properties anywhere in the code including conditional codegen. It is a way of asking if a type “can express this complex set of abstract things or has this enumerated set of properties” with almost arbitrary detail. They are extremely powerful in terms of expressiveness and specialization of code. Insanely good for performance and reliability engineering.
One of the best features to be added to C++ in many years.
C++ contracts are an attempt to bring C asserts into the C++ age. The weakness of C++ contracts is that they are mostly syntactic sugar over C asserts. If you really care about this type of thing, you probably already have a custom C++ assertion framework that is at least as capable if not more.
The promise of C++ contracts is that they can aid formal verification, which would be great. As delivered, it can’t do much more than was already possible, which will inhibit adoption.
The weakness of C++ contracts is that they are mostly syntactic sugar over C asserts.
The sugar is actually one of my issues with them. The evaluation semantics are much more complicated / potentially slower than C asserts because of the sugar, and why you would have to pay those costs isn't obvious at first glance. Lisa Lippincott's excellent talk on the design of contracts [0] is what switched me from a sort of neutral support to disliking it. I think it's a stupid place for the national bodies to draw the line though. std::regex is acceptable, but a nothingburger like contracts tanks the vote?
To be clear, I have a lot of issues with the contracts proposal. I probably wouldn’t use despite living out on the standards frontier. I don’t even use C asserts already because they are not expressive enough in important ways. This proposal kind of reifies the inadequacies.
I think the risk is that C++ contracts become an evolutionary dead-end that hang around forever in code bases because they were standardized. It wouldn’t be the first time this has happened.
I maintain a codebase that I’ve migrated from C++98 to C++11 and all the way to C++23 and even a bit of draft 26 (the latter for some minor library improvements). Few things made me quite as happy as moving from using SFINAE to using requires clauses and concepts.
(IMO the single best improvements over the years have been atomics and maybe variadic templates.)
I think you are right to position atomics and variadic templates as among the most consequential features of C++ in the last couple decades. It made an enormous number of things possible.
One thing I give the C++ feature gods credit for is recognizing material deficiencies in systems languages and unapologetically trying to fill those gaps starting with C++11. The addition of atomics, strict variadics, constexpr, lambdas, concepts, lifetime annotations, etc has been transformative for C++.
> the single best improvements over the years have been atomics...
Of course, libatomic and friends have existed for a long time. Real question: Do you feel that the standardisation of atomics within the C++ base library is a material advantage over using libatomic? Also, maybe there are atomic APIs in the C++ base library that are better than libatomic. If so, please kindly share an example or two. I would like to learn more.
EDIT
I forgot to give a hat tip to your big upgrade from C++98 to C++23. In some projects, that can require an enormous amount of effort! Can you share a "stories from the trenches" that were difficult in that upgrade?
libatomic is a GCC implementation detail that implements atomic math operations that are not available on the target platform by using non-atomic math and compare-exchange. Are you sure that's the one you mean?
Huh? Concepts are types of types. Contracts are fancier, structured runtime assertions. What does one have to do with the other? They're nothing alike.
I don't buy the idea that in "high-reliability C++" every condition worth checking can be checked statically, not unless you define "high-reliability" vacuously as that set of programs for which the claim is true. Real-world programs have legitimate reasons to verify invariants dynamically, and C++26 contracts provides an improved way to do so.
While the C++26 variant of contracts doesn't provide the benefits of its static-analysis-centric ancestor from 2014, and therefore isn't as consequential a feature, it still provides value to some and is absolutely not important enough to be worth killing a standard. Concepts do not provide this value.
In any case, it's simply false that C++26 contracts are unnecessary because we have concepts, yet this claim is the thrust of your initial comment.
> While the C++26 variant of contracts doesn't provide the benefits of its static-analysis-centric ancestor from 2014
Do you have any information as to why they shifted the focus from static analysis to runtime checks? I only remember that it was based on some Microsoft annotation language or something.
The issue is that contracts are less flexible than the existing capabilities in practice, it is limited syntactic sugar.
Contracts were sold with the idea of aiding compile-time verification, a noble purpose. The combination of concepts + constexpr allows you to do deeper compile-time verification today by other means than contracts can check. It isn’t obvious that this will ever not be the case. This means contracts is relegated to being another flavor of C asserts.
C++26 contracts are arguably unnecessary because we can achieve the same results other ways, sometimes with stronger properties. I’m a proponent of features that clean up the syntax but C++ contracts look like a nod to people that still use legacy C asserts. That’s fine but it also perpetuates an inadequate model of what assertions should be capable of expressing.
People figured out how to do with C++20 better than what contracts promised.
There's nothing "legacy" about checking invariants at runtime, and you can't simultaneously dismiss the concerns of people doing so on the grounds that they're "still us[ing] legacy C asserts" when you deny them an alternative to "legacy C asserts". That's question-begging.
> People figured out how to do with C++20 better than what contracts promised.
What contracts used to promise is irrelevant. The contracts on the table modernized runtime assertions and are irrelevant to concepts, constexpr, and related facilities.
Is the contracts feature more useful than C's assert()?
If you want to argue that we're better off with the old macro, do so directly. Concepts, in this context, amount to irrelevant distraction.
I have no issues with people check invariants at runtime. It is unavoidable. C++ contracts is a mediocre way of doing it. Many C++ code bases don’t use any macros at all for assertions and haven’t for a long time. Their models are much more nuanced than C++ contracts allows.
Why would anyone that already ditched C asserts use C++ contracts when it can’t express what the alternatives already can? This isn’t a new problem. People were creating more expressive assertion replacements than contracts offers a decade ago.
C++ contracts are nerfed. It is less expressive and capable than what anyone that cares about these things already uses. So who is expected to use it?
They both start with the letter C, have two syllables, and have/had a hard time getting into the standard. If you’re not paying close attention, it’s easy to get them confused.
The problem is that the current design doesn't take into account binary libraries, or what happens when conflicting contract modes are linked together, as contracts aren't reflected on ABI.
Additionally they offer very little mechanisms versus Eiffel's original design, Ada/SPARK or Frama-C.
A basic MVP, expected to improve on subsequent C++ version, assuming that the proposal authors stick around for those evolution proposals.
This is fascinating to watch from the outside, because there was a big debate a few years ago about whether rust should go for ISO certification, and the consensus seemed to be it was a massive bureaucratic headache with few upsides. Not having a lot of insight into ISO procedures, I wasn't sure what to make of that, but this certainly gives some weight to that point of view
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.
Agree. There's an argument that Contracts reduces the complexity of using the language because it offers a more readable alternative to template metaprogramming (also, it has better error messages). But the argument really falls apart when you review WG21's track record for other features.
Like for example, Coroutines were billed as an easier way to write concurrent code, but personally I think it completely failed and ended up being hopelessly complex and confusing. Modules are the same - superficially they make things simpler, but when people actually go to adopt it, the details are so complex that nobody bothers.
> There's an argument that Contracts reduces the complexity of using the language because it offers a more readable alternative to template metaprogramming
Like most people in this thread, you should really read up on contracts before commenting. The contracts proposal is for runtime assertions, and their problem is that they are poorly specified and fundamentally broken. Their proponents haven't been addressing any of their concerns and tried to push a half baked version of them down everyone's throats, which was why they failed to pass.
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.
Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.
I think the ISO panel made the right call. The real world consider memory safety & execution integrity to already be critical issues (and C++ no longer to be viable), and they are correct. The WG has its priorities wrong.
Memory safety can also be bypassed in Rust. If you want something where memory safety is guaranteed, use Fil-C but this comes at a performance cost. Or use formal verification, where then contracts can help (but C++'s complexity doesn't).
C and formal verification is an awesome combination. I tried cmbc on some toy programs, it it fully automatically proved memory safety and all assertions. But for larger programs one has to split up with a contract-like facility.
Can you tell us more how you use cbmc with macros? I am also exploring this.
I also wonder what feature from C++ you miss in C?
Who cares about the ABI when the current ABI has a bunch of bad issues with it. For any backwards compatibility thing there is always AI that can rewrite old code.
As an avid non-C++ programmer, can I suggest doing something about the build/module system? I shouldn't have to learn a separate language (CMake) and figure out the right include files to pull in a library.
I mean, I mainly say this to joke because it's probably unfixable at this point, but whenever I mess with it, I'm struck by how hard/opaque C++ makes this problem compared to most other languages.
The (lack of any) build system is actually nice for flexibility. You can lay out files however you want, link together random object files without extra work, use your own weird dependency tracking, etc. Obviously it's not super easy to get started with compared to Rust et al. but choosing C++ in the first place implies some need for industrial grade features or unusual setup.
Sure, but JS has a myriad of choices too and yet we mostly agree on node_modules, package.json and npm (the repo). Big companies or weirdos are free to swap any of those with something else if they want but the little guys have something standardish if they don't want to inflict too much pain upon themselves.
There is no standard build/module system or way of dependency management. Unfortunately, this is because there's no standard compiler with standardized flags so C++ would also have to standardize compiler behaviour too.
Large FAANGs that would be incentivized to change it don't care because they have their own in-house C++ build systems like bazel (Google) or buck2 (Meta) that are far faster than cmake (distributed compilation and caching) but require huge teams to maintain. Unfortunately, this distributed compilation and caching layer is something that many other languages don't have since their build systems are made for single devs building locally.
Also the dependencies can be added in a myriad of ways. Your build system can download them, your meta-build dependency manager can find them (Conan), your Linux distro can provide them (system libraries), or maybe you just download an object file from a website + some headers and are told to figure it out yourself (many commercial packages like cuda or steam).
No. The problem isn’t that std::regex is slow and badly designed. It’s that std::regex exists at all.
C++ is unique in that it defines a spec for STL but not implementation. The result is something that is both overspecified and underspecified.
Including batteries is fine. Including a spec for what the batteries should look like is such a profoundly bad idea that no other major language does it.
I'm confused about what exactly you're arguing for. Is the idea that the standard library should be minimal and then each compiler should ship its own nonstandard "batteries" library?
I think the language committee should provide a spec where required (OS filesystem, mutex, etc). And when it is not required they should simply provide a plain bog standard library.
There is absolutely no reason for std::deque to be a specification. The committee should either ship a committee library for std::deque or they should leave it to the community. They can provide a battery or they can not. Providing a spec for a battery that is both over and under specified is the absolute worst possible choice.
Compilers are complex, platform specific and the architectures behind them can be wildly different. Maintaining a reference compiler would be a lot of work for no real benefit.
The standard library on the other hand is a library. It's almost always implemented as plain C++ without much platform specific code. ISO could take an existing free licensed implementation and declare it as the standard. Of course anyone is free to make their own competing one, it just has to always match the official library's behavior.
Writing a spec instead of code is just creating duplicate work and compatibility issues any time the spec is unclear.
The difference is that I can trivially write a std::deque container that runs under any compiler that implements the C++ spec.
Why on earth would I want a different implementation of std::deque on each platform I use because the compiler team needed to provide one? It’s madness!
This article makes it sound the options are normally approval, rejection and abstention, but that this time round a fourth option, "disapproval", was reached. It that the case, or are they just trying to say that people rejected it?
> 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?
I don't get it either; and have no sides on the fence (been years since I wrote C++; but I have before).
It sounds like there's sufficiently different genuine views here on whether it's right for the standard at this time, and this seems like the process working as designed.
A more charitable interpretation is something like royal assent for laws. Yes, the king/queen can always just choose to delay it or even block the law, but that'd be unprecedented and the whole system of parliamentary monarchy would be in a serious crisis.
I think the author is trying to get at like, the actual discussion happens earlier / on the WG21 level, and the ISO vote is treated more of a rubberstamp. And that has changed in this instance.
Personally, I think that if a system to veto something exists, it shouldn't be considered shocking or a betrayal of it gets exercised. Otherwise why have the system?
Not really. The unprecedented part was how come contracts proponents decided to push a proposal against all feedback and concerns, knowing very well it was falling to build up any form of consensus.
Contracts proponents knew for years the featured proposal was opposed as it was riddled with fundamental technical flaws. The unprecedented part was the way they said "screw them" and pushed forth anyway, hoping the formality would build enough pressure to force anyone opposing the feature to succumb to the bureaucratic pressure and silence their concerns.
This contracts stunt reeks of corporate chicanery. I mean, what was the plan here? Ignore everyone, get the bureaucratic foot in the door, and then blackmail all dissenting voices of sabotaging the process if contracts proponents didn't had their way?
The Section "The Process" does explain the thinking behind that statement. To rehash: The author thinks that NB's were trusted with the ability to reject by blocking minority for the case that there is new information, but have used that ability in a case where there was no new information.
I have no stake in this entire discussion or C++ and don't know if the premise of this argument is even true. Just curious: is that thinking unhinged?
It makes big companies and gov bodies happier since and code investment is guaranteed to run with competitors tool chains. You’re not locked in to one vendor, it is an international spec.
I think before I was born, there was just a ton of (closed-source) C compilers for different systems. So people were like "we should have a standard, so our safety critical application doesn't break when we decide to use a <new hardware vendor's> C compiler."
I also think since compiler infrastructure has improved so much, and everything is open source now ... so idk if it matters as much anymore.
There is no need for a language to be "special" just to get standardized.
The main driver is a group of people willing to submit the necessary documents to ISO (or national bodies like ANSI or DIN or even IEEE, and then ISO may also adopt existing standards as theirs).
COBOL, FORTRAN and Pascal are all ISO Standards [1,2,3].
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.
Yes that's right, and from following some threads on reddit about this, he used some really dirty tactics to get it to fail, like scheduling certain snap elections to happen with very short notice at times of the day when people who would oppose his point of view would likely be asleep.
Reddit is a cesspool, I wouldn't put faith in anything you read there.
There were no "dirty tricks". The C++ standards committee works by a vaguely defined "consensus", which requires more than "the majority rules". Contracts got added to the C++26 draft. Then there was consensus that Contracts needed to be fixed, but they could never get consensus on any particular fix. So they cruised along relatively unchanged.
In the end, the only way to NOT accept a marginal Contracts feature was to vote down the full language spec. Now they'll regroup and decide how to proceed.
> ...at times of the day when people who would oppose his point of view would likely be asleep.
Stroustrup is 75 years old. This is not only hard to believe because of his age, but also because it requires that people who oppose his views somehow have distinct sleeping patterns from ones who agree with his views. Weird, man.
> that people who oppose his views somehow have distinct sleeping patterns from ones who agree with his views.
Not weird if they're mostly from different continents.
When I saw him a year or so ago he said he wasn't happy with how things were going, but never alluded to a coup. But it's his language, so good for him.
> 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 (...)
I've noticed that Bjarne Stroustrup is being subjected to a smear campaign, when things are far simpler and far less conspiratorial than they are making out to be.
There are indeed papers demonstrating that not only is the current proposal for contracts broken but it also fails to adhere to core C++ principles. They have been published since at least 2017. Contracts aren't new, nor the problems they introduced. They've been routinely removed from C++ standards, and so far the proposal wasn't fixed.
So ask yourself this: why was a notoriously broken feature forced into the proposal when it was clear it wasn't going to pass?
From an outsider's point of view, I see this from a different perspective. Contracts proponents tried to use bureaucratic tricks and threats of abnormal processes to force a broken feature they knew for years that wasn't supported or passing the smell test. And now that they saw their efforts thwarted , the complain that their plan failed and they have opposition?
I mean, there is even a paper dating back to 2025 called "contracts concerns" and from 2026 called "contracts fundamental flaws". The C++ standard is a consensus-driven process. Does this look like consensus? Clearly no.
So we have a group of people who ignored the calls that they were pushing a broken feature, but tried to railroad the process anyway and ignore any concern or warning. Then, when they tried to force their way through the process, their bluff was called and their threats failed. And now they are lashing back.
I would really love to know: who are the people pushing the current version of contracts, who do they work for, and why does the current version of contracts meet their needs if it's so flawed?
Bjarne Stroustrup has been pushing Profiles, which would allow C++ code (or the majority of it) to become type-safe and memory safe.
Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.
I think the ISO panel made the right call. The real world consider memory safety & execution integrity to be critical issues, and C++ no longer to be viable. Without some major improvements -- I would consider this view to be correct.
> Profiles, which would allow C++ code (or the majority of it) to become type-safe and memory safe.
Certainly safer, but not memory safe. Operations as simple as multiplying signed integers or popping an empty vec can be undefined behavior which is not memory safe.
For most domains, it is fine. Why should my valued checked code pay the price for checking every arithmetic operation for overflow. Why should my correctly implemented algorithm waste CPU checking something I know is valid? And worst of all, what happens when a logic error is encountered, we run untested code path? I hate code that is conditionally defensive (eg. if (ptr) ptr->critical(); ). I should never be in that situation, a silent ignore corrupts internal state, and never tested the fail path. Ptr may even refer to garbage. Its a stupid defebsive check in 90% of code bases. std::optional<Ptr> at least clarifies intent.
SIMD cannot be solved at the compiler level. The capabilities of silicon SIMD implementations are fundamentally so disjoint that code using SIMD requires contextual and platform-specific data structures and algorithms.
SIMD on different silicon is incompatible at layers of abstraction far above the codegen manipulation a compiler can do.
You'll never get the full feature set of all SIMD implementations in a single generic abstraction but I'm not sure that's the only way a SIMD abstraction could provide value. There is a pretty consistent set of narrow SIMD that behaves close enough to consistently get better performance across generic targets with high level abstractions better than auto vectorized scalar code but worse than platform tuned SIMD.
The subset of SIMD that translates is so narrow that it is almost useless in real code. That’s the problem. Additionally, it is invalid for the compiler to redesign your data structures.
The ability of compilers to use SIMD is no better than it was 20 years ago. Total stagnation for all practical purposes, and the reason is that compilers fundamentally lack the context and freedom to rewrite the code architecture appropriately for SIMD optimization (even if they could).
I think a point people miss is that highly optimized SIMD code is almost never about parallelizing loops. It is about deeply probing and manipulating arbitrarily complex data structures in parallel that involve collections of unrelated types. SIMD allows you to do this, and it is fantastically efficient, but a compiler has no conceivable way of understanding this.
For this reason, SIMD optimization has often been classified as an AI-Complete problem in computer science.
My imagination is failing me, can you give me an example of the type of work being done where SIMD is ‘deeply probing and manipulating arbitrarily complex data structures in parallel that involve collections of unrelated types’? I don’t doubt you know what you mean, but I can’t wrap my head around it.
For me I can only think of the simplest example of SIMD being used to ‘parallelize loops’ as what SIMD is for. If it turns out I’m missing a large problem or application space for SIMD I will be excited to research it. Any pointers to topics would be appreciated.
One example is OLAP databases, which often heavily exploit SIMD for query processing. You can also turn parsing into a SIMD problem, which is applicable to things like handling XML, JSON, and CSV. Simdjson comes to mind, or parabix for XML.
SIMD is often used to evaluate complex data structures in parallel. A common case is given a row with an arbitrary mix of data types and a query with an arbitrary mix of independent constraints on those data types, to evaluate all of the constraints in parallel in the same SIMD instruction(s).
The idea that SIMD is only good for parallelizing operations over arrays of the same type is empirically false and seriously understates the capabilities of good SIMD implementations. Some SQL-ish implementations work this way on row-structured data.
Most devs seriously underestimate what good SIMD is capable of.
Is the common feature set described anywhere online? I am not in the SIMD world, and I am curious about the state of it. But I am not so committed that I am wiling to learn several different platforms’ SIMD implementations in order to suss out their commonalities.
There are frameworks trying to unify simd/avx, but the abstractions aren't free. At this point, we need better hardware and low level interfaces, not better abstractions.
An implementation of which exists in the following GitHub repo (albeit implemented in the xvec::simd namespace rather than std::simd...but otherwise intended to be spec-compliant).
Speaking as a long-time C++ developer...I wasn't uninterested in contracts (which I've known about since the days of Bertrand Meyer flogging them in Eiffel), but I agree with the sentiment here that the SIMD efforts were considerably more interesting.
I disapprove what they do to c++ for many years now, but nobody cares. I had hoped for c++ what has become c#. Well now i use c# with c if i need the speed
If I want to spin up a new project with a coding agent to explore some idea and I'd like the bare metal performance, why would I choose C++ over Rust?
I could choose TypeScript over Rust if I wanted it to be html first or I could choose Go if I wanted it to be clear of the complexity of memory management or I could choose C# if I wanted it to have best interface with windows stuff or I could choose something Erlang VM based for resilience and multithreading.
Maybe you don't. If you were to spin up a new project with a coding agent most of the subsequent highlights of the languages you cited might also not matter.
You'll find plenty of info if you search for anything like "c++ contracts" [0], but the short of it is that they're just pre/post conditions on functions. Slightly improved assertions, basically.
cppreference is often a bit too technical for its own good :)
But I think there's a broader issue which is that if it took me multiple searches to find a good-enough visual "pitch" for what contracts look like in practice, its champions have not yet won hearts and minds - which brings us to the situation at hand.
Its a very inside baseball article. Contracts is a proposed C++ language feature for improving programmable assertions of program state. E.g. a better c++ version of C's assert function. That in theory will improve both safety and performance by letting people add more complex assertions (e.g. pre/post conditions) to functions.
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.
I wouldn't choose Rust because of compile times. C++ ones aren't great either, but with discipline in how you structure headers, you can get reasonable compile speeds. Unsafe Rust is also a bit of a PITA, and I have cases where I care lot about precisely how memory is laid out and accessed, I'd have to resort to it quite a lot. I don't love crates either, they smell a bit like node_modules and all big Rust projects I've seen have hundreds of them. Most C++ libraries are self contained, by nature of not having an easy way to declare dependencies.
I wouldn't choose Go because GC is a non-starter.
I wouldn't choose C because it's nice to have some form of generics or metaprogramming, even if templates are not exactly fantastic.
I wouldn't choose Zig because the language isn't stable, and the lead developer has hinted that they'll drop LLVM down the line, and I don't want to beta test their compiler backend.
I think Rust's saftey guarantees are an important reason to throw it at LLMs. LLMs make stupid mistakes, even the very best ones, and a lot of them, all the time. Having a compiler reject those mistakes makes for a better automated process. C++ has some safety mechanisms as well, but they're weak and fragile compared to Rust.
For people with C++ experience working together months at a time that doesn't have to be a problem, but AI rewrites turn a million lines of one language into a million of the other in a day, followed by an impossibly short human review.
Rust also isn't as safe and correct as you'd hope it to be for "fuck it, let the LLM deal with it" style programming, but it's got the best speed-usability-safety balance out of the common languages if you don't trust your programmers.
The issue that caused this to be voted down is often seen as a memory safety solution (not something I personally 100% agree with, but thats a broad view). And the rest of this release includes other memory safety work. And it was voted down and delayed for apparent political reasons (again not a view I agree with).
So most people will read your view as hypocritical/misinformed.
It could also be read as a straight up attack. Basically, a way of saying “why not follow Rust“ without having to say the word Rust.
I think it was a fair question. As someone who doesn’t follow C++ I really don’t know what else was in the proposal. It’s nice to hear there is memory safety stuff.
The memory-safety-relevant parts of the proposal could be salvaged without keeping contracts more broadly, by saying that the relevant behaviors (like indexing past the end of a std::vector) cause program termination in hardened builds. I'm sure it's more complicated than this but I don't think much more.
More generally, the C++ committee has had a really hard time agreeing on memory-safety stuff because there are a lot of different constituencies with completely different priorities (especially whether they're using it for greenfield vs. legacy vs. something in between), and the incentive is to make proposals sound good to everyone at the expense of actually being coherent.
you know downvoting without explaining why is part of herd mentality. i expected better on HN. dont you wanna give some reasons as to why you find this offensive?
99.9% of all system code in the world is still written in C/++. It runs your Java, C#, Javascript, Python, PHP, basically every production language that isn't Go or Rust. It runs the two most popular game engines in the world. It runs your phone, server, and laptop, no matter which of any you use. It runs your car. It runs almost every embedded and industrial application on the planet.
Is it still relevant, JFC. The way people on this forum manage to sequester themselves from reality. Let me reverse the question: is Rust relevant? Mozilla developed Rust, abandoned their Rust browser, and only 10% of Firefox is written in Rust. Maybe 1% of modules in Chrome and Linux are written in Rust, if that. And what of Rust applications written from scratch? Can you name ten applications that have, say, exposure to more than 100,000 users? Impossible mode: they can't be developer tools only used by other developers (uv, ripgrep, etc.), they must actually be applications used by enterprises or consumers.
I read that as "is c++ still relevant for new features, given Rust and its popularity", not "who is still using C++".
Personally, I think it is still relevant. Many people thought Kotlin could overtake Java, Java reinvented itself with new initiatives/features and was saved from becoming irrelevant.
Rust also has the LLM advantage which is where I think the "if it compiles it works" nature of Rust is easier for manual changes and maintenance when needed.
Java vs. Kotlin is a different matter. It's still an open question if C++ even could match Rust's features, not to say if it (the committee) wants to, and the answer seems to be "no".
C++ is the third most popular programming language according to TIOBE behind C and python. It's got an 8.87% ranking. So yes it looks like C++ is still relevant. In fact C++ usage has risen slightly.
Rust is in tenth place with 1.44% ranking, it's rising fast but still has a long way to go before it catches C++.
I'm not going to speculate about why Rust hasn't yet supplanted C++ but I will say I don't find it surprising.
But, of course, there is still a lot of new C++ code written, more than Rust. I believe C++ will become legacy, but it's not there yet and even once that happens it'll take at least decades to stop writing C++.
A much more accurate snapshot would be Github - they recently published the top langauges for the year (so far, up til Sept 2026) by distinct monthly contributors and C++ comes in at 9 out of the top 10, and Rust doesn't even place in the top 10 yet, so yes it is highly relevant and prevalent, but not because TIOBE said so.
But, TypeScript, Python and Rust are the fastest growing languages, in that order, so also you cannot discount Rust.
You didn't mention why people shouldn't cite TIOBE so I checked. It's because they measure search engine queries to assess popularity. GitHub measures actual code usage in real repos.
I agree the GitHub methodology seems better. I don't think TIOBE methods mean that it's ranking is completely irrelevant but it'll be noisy and you could easily game it.
Even if C++ is irrelevant for new code, there's so much software already written in it that we'll be maintaining it for decades to come. I'd argue that Cobol and Fortran have been mostly obsolete for new code for almost 30 years now, yet both are still widely used today, and they've even had major updates in the past decade [0] [1]. And there's even more software written in C++ than there is in Cobol or Fortran, so I don't think that C++ is going away any time soon.
Essentially all high-end systems code for high-performance and high-reliability systems is still written in modern C++. That language has many attractive properties, including safety features that Rust does not currently support.
Additionally, for pure performance requirements, C++ is still materially faster than Rust in practice. That may change some day. C++ has many issues but it is also objectively excellent at many things.
> Is C++ still relevant? What prevents Rust from completely supplanting it?
A highly mature ecosystem with well-established libraries. Especially in certain fields (DSP, robotics, CAD kernels, microcontrollers, etc.), there are no equivalent libraries and frameworks in Rust with such a proven track record.
Now, LLMs can rewrite those libraries in Rust quite easily. Such options weren't available a few years back. But it's still hard to prove that a rewrite hasn't introduced new bugs. It's easy to demonstrate that a piece of code has bugs, but much harder to prove that it doesn't introduce any new ones.
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.
Perhaps it is, in this case it would be between money and everyone else specifically. Contracts is a pet project of Microsoft and the heavy money parts of the committee. They've basically shouted down the dissenters, hence the effectively unprecedented action of the rubberstamp portion of the process saying they dont think consensus was reached in a kosher way.
No one who developed contracts works for Microsoft. Of the like 20 people who contributed to the feature, 4 of them work for Bloomberg, so you could maybe argue that Bloomberg has a vested interest in the feature, but that's really stretching things.
Support for contracts is fairly broad and spans numerous organizations.
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.
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.
A lot of folks, many of them our most capable programmers, are fighting the last war. It’s like they think AI is going away and we’ll all work like it’s 2019 again.
Not to defend the particular proposal at issue here, but my sense is that contract-like things synergize quite well with AI coding, for the same reasons automated tests and static types do.
> And we have no idea what AI systems will be doing in 2027.
How would you begin to form a plan of how you'll rethink if you can't even see into next year? Isn't it beneficial not to change the languages too much because there's so much training data for the current revisions? AI does not need to be catered to, that is the whole point and why it is useful.
We're going to need languages which both humans and AIs can read and write.
We don't know what those look like yet. Contracts aren't a bad idea, but C++ has just become too big. Even people who used to be C++ language lawyers have said that.
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.
Your comment just made me realize contracts is different from concepts (which are basically bounded genetics, right…?)
Concepts are evaluated compile time and make a lot of TMP more elegant. Contracts are runtime check, akin to assertions.
Phrased differently, contracts are to concepts what assert is to static_assert.
Too bad it couldn't have been contract and static_contract.
Concepts are for Types at compile time while Contracts are for Values at runtime.
C++ concepts evaluate the properties of types at compile-time. You can inject arbitrary constraints on type properties anywhere in the code including conditional codegen. It is a way of asking if a type “can express this complex set of abstract things or has this enumerated set of properties” with almost arbitrary detail. They are extremely powerful in terms of expressiveness and specialization of code. Insanely good for performance and reliability engineering.
One of the best features to be added to C++ in many years.
C++ contracts are an attempt to bring C asserts into the C++ age. The weakness of C++ contracts is that they are mostly syntactic sugar over C asserts. If you really care about this type of thing, you probably already have a custom C++ assertion framework that is at least as capable if not more.
The promise of C++ contracts is that they can aid formal verification, which would be great. As delivered, it can’t do much more than was already possible, which will inhibit adoption.
The sugar is actually one of my issues with them. The evaluation semantics are much more complicated / potentially slower than C asserts because of the sugar, and why you would have to pay those costs isn't obvious at first glance. Lisa Lippincott's excellent talk on the design of contracts [0] is what switched me from a sort of neutral support to disliking it. I think it's a stupid place for the national bodies to draw the line though. std::regex is acceptable, but a nothingburger like contracts tanks the vote?
[0] https://www.youtube.com/watch?v=yhhSW-FSWkE
To be clear, I have a lot of issues with the contracts proposal. I probably wouldn’t use despite living out on the standards frontier. I don’t even use C asserts already because they are not expressive enough in important ways. This proposal kind of reifies the inadequacies.
I think the risk is that C++ contracts become an evolutionary dead-end that hang around forever in code bases because they were standardized. It wouldn’t be the first time this has happened.
What do you do instead of C asserts? Throwing exceptions?
I maintain a codebase that I’ve migrated from C++98 to C++11 and all the way to C++23 and even a bit of draft 26 (the latter for some minor library improvements). Few things made me quite as happy as moving from using SFINAE to using requires clauses and concepts.
(IMO the single best improvements over the years have been atomics and maybe variadic templates.)
I think you are right to position atomics and variadic templates as among the most consequential features of C++ in the last couple decades. It made an enormous number of things possible.
One thing I give the C++ feature gods credit for is recognizing material deficiencies in systems languages and unapologetically trying to fill those gaps starting with C++11. The addition of atomics, strict variadics, constexpr, lambdas, concepts, lifetime annotations, etc has been transformative for C++.
Of course, libatomic and friends have existed for a long time. Real question: Do you feel that the standardisation of atomics within the C++ base library is a material advantage over using libatomic? Also, maybe there are atomic APIs in the C++ base library that are better than libatomic. If so, please kindly share an example or two. I would like to learn more.
EDIT
I forgot to give a hat tip to your big upgrade from C++98 to C++23. In some projects, that can require an enormous amount of effort! Can you share a "stories from the trenches" that were difficult in that upgrade?
libatomic is a GCC implementation detail that implements atomic math operations that are not available on the target platform by using non-atomic math and compare-exchange. Are you sure that's the one you mean?
I want to read your blog describing these experiences.
A concept is a compile time requirement that bounds templates which are the generics in C++, so you are close.
Huh? Concepts are types of types. Contracts are fancier, structured runtime assertions. What does one have to do with the other? They're nothing alike.
Absolutely Right! - https://news.ycombinator.com/item?id=50361435
That’s exactly my point.
Contracts notionally offer the ability to lift some runtime assertions to compile-time. That is how it was sold. Except they don’t in practice.
Meanwhile, concepts + constexpr if used artfully deliver that in practice, including for many cases that contracts were supposed to solve.
I push all verification to compile-time to the extent possible.
I don't buy the idea that in "high-reliability C++" every condition worth checking can be checked statically, not unless you define "high-reliability" vacuously as that set of programs for which the claim is true. Real-world programs have legitimate reasons to verify invariants dynamically, and C++26 contracts provides an improved way to do so.
While the C++26 variant of contracts doesn't provide the benefits of its static-analysis-centric ancestor from 2014, and therefore isn't as consequential a feature, it still provides value to some and is absolutely not important enough to be worth killing a standard. Concepts do not provide this value.
In any case, it's simply false that C++26 contracts are unnecessary because we have concepts, yet this claim is the thrust of your initial comment.
> While the C++26 variant of contracts doesn't provide the benefits of its static-analysis-centric ancestor from 2014
Do you have any information as to why they shifted the focus from static analysis to runtime checks? I only remember that it was based on some Microsoft annotation language or something.
The issue is that contracts are less flexible than the existing capabilities in practice, it is limited syntactic sugar.
Contracts were sold with the idea of aiding compile-time verification, a noble purpose. The combination of concepts + constexpr allows you to do deeper compile-time verification today by other means than contracts can check. It isn’t obvious that this will ever not be the case. This means contracts is relegated to being another flavor of C asserts.
C++26 contracts are arguably unnecessary because we can achieve the same results other ways, sometimes with stronger properties. I’m a proponent of features that clean up the syntax but C++ contracts look like a nod to people that still use legacy C asserts. That’s fine but it also perpetuates an inadequate model of what assertions should be capable of expressing.
People figured out how to do with C++20 better than what contracts promised.
There's nothing "legacy" about checking invariants at runtime, and you can't simultaneously dismiss the concerns of people doing so on the grounds that they're "still us[ing] legacy C asserts" when you deny them an alternative to "legacy C asserts". That's question-begging.
> People figured out how to do with C++20 better than what contracts promised.
What contracts used to promise is irrelevant. The contracts on the table modernized runtime assertions and are irrelevant to concepts, constexpr, and related facilities.
Is the contracts feature more useful than C's assert()?
If you want to argue that we're better off with the old macro, do so directly. Concepts, in this context, amount to irrelevant distraction.
I have no issues with people check invariants at runtime. It is unavoidable. C++ contracts is a mediocre way of doing it. Many C++ code bases don’t use any macros at all for assertions and haven’t for a long time. Their models are much more nuanced than C++ contracts allows.
Why would anyone that already ditched C asserts use C++ contracts when it can’t express what the alternatives already can? This isn’t a new problem. People were creating more expressive assertion replacements than contracts offers a decade ago.
C++ contracts are nerfed. It is less expressive and capable than what anyone that cares about these things already uses. So who is expected to use it?
They both start with the letter C, have two syllables, and have/had a hard time getting into the standard. If you’re not paying close attention, it’s easy to get them confused.
I never heard this term used with C++ before. Can you explain more? Ideally: Can you give an example snip of code that demonstrates it clearly?
Its a set of rules, used by defense software, they are available on the internet
For example the failed F-35 project used it. Seems pretentious and risky compared to using a language that is safe by default.
> compared to a language that is safe by default.
This also sounds pretentious ...
Top 2 Google search result are ..: this post and this article
The problem is that the current design doesn't take into account binary libraries, or what happens when conflicting contract modes are linked together, as contracts aren't reflected on ABI.
Additionally they offer very little mechanisms versus Eiffel's original design, Ada/SPARK or Frama-C.
A basic MVP, expected to improve on subsequent C++ version, assuming that the proposal authors stick around for those evolution proposals.
This is fascinating to watch from the outside, because there was a big debate a few years ago about whether rust should go for ISO certification, and the consensus seemed to be it was a massive bureaucratic headache with few upsides. Not having a lot of insight into ISO procedures, I wasn't sure what to make of that, but this certainly gives some weight to that point of view
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.
Agree. There's an argument that Contracts reduces the complexity of using the language because it offers a more readable alternative to template metaprogramming (also, it has better error messages). But the argument really falls apart when you review WG21's track record for other features.
Like for example, Coroutines were billed as an easier way to write concurrent code, but personally I think it completely failed and ended up being hopelessly complex and confusing. Modules are the same - superficially they make things simpler, but when people actually go to adopt it, the details are so complex that nobody bothers.
I think you're confusing it with Concepts. Contracts are basically just asserts, nothing to do with templates.
> There's an argument that Contracts reduces the complexity of using the language because it offers a more readable alternative to template metaprogramming
Like most people in this thread, you should really read up on contracts before commenting. The contracts proposal is for runtime assertions, and their problem is that they are poorly specified and fundamentally broken. Their proponents haven't been addressing any of their concerns and tried to push a half baked version of them down everyone's throats, which was why they failed to pass.
Some do bother, e.g. Microsoft Office uses modules, there is a talk on it.
*sheer
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.
Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.
I think the ISO panel made the right call. The real world consider memory safety & execution integrity to already be critical issues (and C++ no longer to be viable), and they are correct. The WG has its priorities wrong.
Memory safety can also be bypassed in Rust. If you want something where memory safety is guaranteed, use Fil-C but this comes at a performance cost. Or use formal verification, where then contracts can help (but C++'s complexity doesn't).
C and formal verification is an awesome combination. I tried cmbc on some toy programs, it it fully automatically proved memory safety and all assertions. But for larger programs one has to split up with a contract-like facility.
Can you tell us more how you use cbmc with macros? I am also exploring this.
I also wonder what feature from C++ you miss in C?
Well i you ask me i miss namespaces and functions i could put into struct and enum types
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.
Maybe a slightly faster std::regex or whatever it's called; apparently it's horrendously slow for no benefit.
Ranges need work as well, there’s lot of opportunity to improve things there.
The primary reason this hasn't happened is that it'd break C++'s de facto stable ABI (even though officially there's no such thing). For a lot more context, see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20... and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18....
Spoiler alert: The option described as "the sort of leadership failing that I pray we can avoid" is what ended up happening.
Who cares about the ABI when the current ABI has a bunch of bad issues with it. For any backwards compatibility thing there is always AI that can rewrite old code.
The compiler vendors care. It is also the reason why C++ never actually had a GC, even if the standard had it specified (and removed it with C++23).
As an avid non-C++ programmer, can I suggest doing something about the build/module system? I shouldn't have to learn a separate language (CMake) and figure out the right include files to pull in a library.
I mean, I mainly say this to joke because it's probably unfixable at this point, but whenever I mess with it, I'm struck by how hard/opaque C++ makes this problem compared to most other languages.
The (lack of any) build system is actually nice for flexibility. You can lay out files however you want, link together random object files without extra work, use your own weird dependency tracking, etc. Obviously it's not super easy to get started with compared to Rust et al. but choosing C++ in the first place implies some need for industrial grade features or unusual setup.
Sure, but JS has a myriad of choices too and yet we mostly agree on node_modules, package.json and npm (the repo). Big companies or weirdos are free to swap any of those with something else if they want but the little guys have something standardish if they don't want to inflict too much pain upon themselves.
There is no standard build/module system or way of dependency management. Unfortunately, this is because there's no standard compiler with standardized flags so C++ would also have to standardize compiler behaviour too.
Large FAANGs that would be incentivized to change it don't care because they have their own in-house C++ build systems like bazel (Google) or buck2 (Meta) that are far faster than cmake (distributed compilation and caching) but require huge teams to maintain. Unfortunately, this distributed compilation and caching layer is something that many other languages don't have since their build systems are made for single devs building locally.
Also the dependencies can be added in a myriad of ways. Your build system can download them, your meta-build dependency manager can find them (Conan), your Linux distro can provide them (system libraries), or maybe you just download an object file from a website + some headers and are told to figure it out yourself (many commercial packages like cuda or steam).
It's probably possible to improve things here, but it's likely best done as a separate open source project.
No. The problem isn’t that std::regex is slow and badly designed. It’s that std::regex exists at all.
C++ is unique in that it defines a spec for STL but not implementation. The result is something that is both overspecified and underspecified.
Including batteries is fine. Including a spec for what the batteries should look like is such a profoundly bad idea that no other major language does it.
I'm confused about what exactly you're arguing for. Is the idea that the standard library should be minimal and then each compiler should ship its own nonstandard "batteries" library?
I think the language committee should provide a spec where required (OS filesystem, mutex, etc). And when it is not required they should simply provide a plain bog standard library.
There is absolutely no reason for std::deque to be a specification. The committee should either ship a committee library for std::deque or they should leave it to the community. They can provide a battery or they can not. Providing a spec for a battery that is both over and under specified is the absolute worst possible choice.
Do you also think the committee should ship a compiler? If not, what's the difference?
Compilers are complex, platform specific and the architectures behind them can be wildly different. Maintaining a reference compiler would be a lot of work for no real benefit.
The standard library on the other hand is a library. It's almost always implemented as plain C++ without much platform specific code. ISO could take an existing free licensed implementation and declare it as the standard. Of course anyone is free to make their own competing one, it just has to always match the official library's behavior.
Writing a spec instead of code is just creating duplicate work and compatibility issues any time the spec is unclear.
The difference is that I can trivially write a std::deque container that runs under any compiler that implements the C++ spec.
Why on earth would I want a different implementation of std::deque on each platform I use because the compiler team needed to provide one? It’s madness!
This article makes it sound the options are normally approval, rejection and abstention, but that this time round a fourth option, "disapproval", was reached. It that the case, or are they just trying to say that people rejected it?
It was rejected because it did not receive the required 2/3 majority for approval.
> 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.
Constraining yourself with the C++11 feature set in the age of agentic coding, yikes.
Using C++ in the age of agentic coding, yikes
Not using C++ in the age of agentic coding, yikes
Agentic coding is only possible thanks to C++, not Python.
Approval of runtime failures essentially failed at runtime
> 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?
I don't get it either; and have no sides on the fence (been years since I wrote C++; but I have before).
It sounds like there's sufficiently different genuine views here on whether it's right for the standard at this time, and this seems like the process working as designed.
Because they didn’t vote the way the author wanted them to.
That’s not very charitable, but honestly I’ve been trying for five minutes now to find or think up an alternative explanation. And coming up blank.
A more charitable interpretation is something like royal assent for laws. Yes, the king/queen can always just choose to delay it or even block the law, but that'd be unprecedented and the whole system of parliamentary monarchy would be in a serious crisis.
I think the author is trying to get at like, the actual discussion happens earlier / on the WG21 level, and the ISO vote is treated more of a rubberstamp. And that has changed in this instance.
Personally, I think that if a system to veto something exists, it shouldn't be considered shocking or a betrayal of it gets exercised. Otherwise why have the system?
> but that'd be unprecedented
Not really. The unprecedented part was how come contracts proponents decided to push a proposal against all feedback and concerns, knowing very well it was falling to build up any form of consensus.
Contracts proponents knew for years the featured proposal was opposed as it was riddled with fundamental technical flaws. The unprecedented part was the way they said "screw them" and pushed forth anyway, hoping the formality would build enough pressure to force anyone opposing the feature to succumb to the bureaucratic pressure and silence their concerns.
This contracts stunt reeks of corporate chicanery. I mean, what was the plan here? Ignore everyone, get the bureaucratic foot in the door, and then blackmail all dissenting voices of sabotaging the process if contracts proponents didn't had their way?
> Because they didn’t vote the way the author wanted them to.
That's my opinion as well. It's a smear campaign lashing back at people who dared to point out flaws.
The Section "The Process" does explain the thinking behind that statement. To rehash: The author thinks that NB's were trusted with the ability to reject by blocking minority for the case that there is new information, but have used that ability in a case where there was no new information.
I have no stake in this entire discussion or C++ and don't know if the premise of this argument is even true. Just curious: is that thinking unhinged?
How did C/C++ get into ISO? Why are they "special" compared to other languages? Just because they are old and ubiquitous in all systems programming?
The whole design committee procedure around these languages feels like a bureaucratic nightmare, again compared to other languages, especially Rust.
It makes big companies and gov bodies happier since and code investment is guaranteed to run with competitors tool chains. You’re not locked in to one vendor, it is an international spec.
I think before I was born, there was just a ton of (closed-source) C compilers for different systems. So people were like "we should have a standard, so our safety critical application doesn't break when we decide to use a <new hardware vendor's> C compiler."
I also think since compiler infrastructure has improved so much, and everything is open source now ... so idk if it matters as much anymore.
> Why are they "special" compared to other languages?
The world basically runs on C.
Isn’t Rust also suffering from committee deadlock for the past couple years?
There is no need for a language to be "special" just to get standardized.
The main driver is a group of people willing to submit the necessary documents to ISO (or national bodies like ANSI or DIN or even IEEE, and then ISO may also adopt existing standards as theirs).
COBOL, FORTRAN and Pascal are all ISO Standards [1,2,3].
[1] https://www.iso.org/standard/74527.html
[2] https://www.iso.org/standard/82170.html
[3] https://www.iso.org/standard/13802.html
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.
Yes that's right, and from following some threads on reddit about this, he used some really dirty tactics to get it to fail, like scheduling certain snap elections to happen with very short notice at times of the day when people who would oppose his point of view would likely be asleep.
So is he a hero, or villain? Does it all come down to concepts?
Not concepts, contracts.
Reddit is a cesspool, I wouldn't put faith in anything you read there.
There were no "dirty tricks". The C++ standards committee works by a vaguely defined "consensus", which requires more than "the majority rules". Contracts got added to the C++26 draft. Then there was consensus that Contracts needed to be fixed, but they could never get consensus on any particular fix. So they cruised along relatively unchanged.
In the end, the only way to NOT accept a marginal Contracts feature was to vote down the full language spec. Now they'll regroup and decide how to proceed.
> ...at times of the day when people who would oppose his point of view would likely be asleep.
Stroustrup is 75 years old. This is not only hard to believe because of his age, but also because it requires that people who oppose his views somehow have distinct sleeping patterns from ones who agree with his views. Weird, man.
> that people who oppose his views somehow have distinct sleeping patterns from ones who agree with his views.
Not weird if they're mostly from different continents.
When I saw him a year or so ago he said he wasn't happy with how things were going, but never alluded to a coup. But it's his language, so good for him.
If this was true I'd ask myself why he was this motivated to block it. He's a smart man and not a corpo rat to do dirty things just because.
> 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 (...)
I've noticed that Bjarne Stroustrup is being subjected to a smear campaign, when things are far simpler and far less conspiratorial than they are making out to be.
There are indeed papers demonstrating that not only is the current proposal for contracts broken but it also fails to adhere to core C++ principles. They have been published since at least 2017. Contracts aren't new, nor the problems they introduced. They've been routinely removed from C++ standards, and so far the proposal wasn't fixed.
So ask yourself this: why was a notoriously broken feature forced into the proposal when it was clear it wasn't going to pass?
From an outsider's point of view, I see this from a different perspective. Contracts proponents tried to use bureaucratic tricks and threats of abnormal processes to force a broken feature they knew for years that wasn't supported or passing the smell test. And now that they saw their efforts thwarted , the complain that their plan failed and they have opposition?
I mean, there is even a paper dating back to 2025 called "contracts concerns" and from 2026 called "contracts fundamental flaws". The C++ standard is a consensus-driven process. Does this look like consensus? Clearly no.
So we have a group of people who ignored the calls that they were pushing a broken feature, but tried to railroad the process anyway and ignore any concern or warning. Then, when they tried to force their way through the process, their bluff was called and their threats failed. And now they are lashing back.
I would really love to know: who are the people pushing the current version of contracts, who do they work for, and why does the current version of contracts meet their needs if it's so flawed?
Bjarne Stroustrup has been pushing Profiles, which would allow C++ code (or the majority of it) to become type-safe and memory safe.
Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.
I think the ISO panel made the right call. The real world consider memory safety & execution integrity to be critical issues, and C++ no longer to be viable. Without some major improvements -- I would consider this view to be correct.
> Profiles, which would allow C++ code (or the majority of it) to become type-safe and memory safe.
Certainly safer, but not memory safe. Operations as simple as multiplying signed integers or popping an empty vec can be undefined behavior which is not memory safe.
For most domains, it is fine. Why should my valued checked code pay the price for checking every arithmetic operation for overflow. Why should my correctly implemented algorithm waste CPU checking something I know is valid? And worst of all, what happens when a logic error is encountered, we run untested code path? I hate code that is conditionally defensive (eg. if (ptr) ptr->critical(); ). I should never be in that situation, a silent ignore corrupts internal state, and never tested the fail path. Ptr may even refer to garbage. Its a stupid defebsive check in 90% of code bases. std::optional<Ptr> at least clarifies intent.
> Now it gets complicated.
It was said in the article about the process.
But to me this is relevant to the state of the language itself.
C++ should focus into turning SIMD into a higher level language instead of being a giant collection of intrinsics. Avx code is unreadable.
SIMD cannot be solved at the compiler level. The capabilities of silicon SIMD implementations are fundamentally so disjoint that code using SIMD requires contextual and platform-specific data structures and algorithms.
SIMD on different silicon is incompatible at layers of abstraction far above the codegen manipulation a compiler can do.
You'll never get the full feature set of all SIMD implementations in a single generic abstraction but I'm not sure that's the only way a SIMD abstraction could provide value. There is a pretty consistent set of narrow SIMD that behaves close enough to consistently get better performance across generic targets with high level abstractions better than auto vectorized scalar code but worse than platform tuned SIMD.
The subset of SIMD that translates is so narrow that it is almost useless in real code. That’s the problem. Additionally, it is invalid for the compiler to redesign your data structures.
The ability of compilers to use SIMD is no better than it was 20 years ago. Total stagnation for all practical purposes, and the reason is that compilers fundamentally lack the context and freedom to rewrite the code architecture appropriately for SIMD optimization (even if they could).
I think a point people miss is that highly optimized SIMD code is almost never about parallelizing loops. It is about deeply probing and manipulating arbitrarily complex data structures in parallel that involve collections of unrelated types. SIMD allows you to do this, and it is fantastically efficient, but a compiler has no conceivable way of understanding this.
For this reason, SIMD optimization has often been classified as an AI-Complete problem in computer science.
Couldn't SIMD features include marking data as "the compiler is free to rearrange"?
My imagination is failing me, can you give me an example of the type of work being done where SIMD is ‘deeply probing and manipulating arbitrarily complex data structures in parallel that involve collections of unrelated types’? I don’t doubt you know what you mean, but I can’t wrap my head around it.
For me I can only think of the simplest example of SIMD being used to ‘parallelize loops’ as what SIMD is for. If it turns out I’m missing a large problem or application space for SIMD I will be excited to research it. Any pointers to topics would be appreciated.
One example is OLAP databases, which often heavily exploit SIMD for query processing. You can also turn parsing into a SIMD problem, which is applicable to things like handling XML, JSON, and CSV. Simdjson comes to mind, or parabix for XML.
The parsing stuff I am aware of, but the query processing is a big blank for me to dig into.
SIMD is often used to evaluate complex data structures in parallel. A common case is given a row with an arbitrary mix of data types and a query with an arbitrary mix of independent constraints on those data types, to evaluate all of the constraints in parallel in the same SIMD instruction(s).
The idea that SIMD is only good for parallelizing operations over arrays of the same type is empirically false and seriously understates the capabilities of good SIMD implementations. Some SQL-ish implementations work this way on row-structured data.
Most devs seriously underestimate what good SIMD is capable of.
Thanks for the response, I’ll have some reading to do in this area.
Is the common feature set described anywhere online? I am not in the SIMD world, and I am curious about the state of it. But I am not so committed that I am wiling to learn several different platforms’ SIMD implementations in order to suss out their commonalities.
That's why it needs a lot of work. Writing SIMD in c++ is like writing assembly.
> SIMD cannot be solved at the compiler level.
ISPC doesn't a pretty good job of it: https://ispc.github.io/
There are frameworks trying to unify simd/avx, but the abstractions aren't free. At this point, we need better hardware and low level interfaces, not better abstractions.
In fact, C++26 made some considerable progress on that front.
https://en.cppreference.com/cpp/experimental/simd
An implementation of which exists in the following GitHub repo (albeit implemented in the xvec::simd namespace rather than std::simd...but otherwise intended to be spec-compliant).
https://github.com/intel/xvec
Speaking as a long-time C++ developer...I wasn't uninterested in contracts (which I've known about since the days of Bertrand Meyer flogging them in Eiffel), but I agree with the sentiment here that the SIMD efforts were considerably more interesting.
major C++26 features, including reflection, std::execution and library hardening, are also delayed because they were included in the same draft.
No they are not. The standard may be delayed but most compilers ship these features already.
I disapprove what they do to c++ for many years now, but nobody cares. I had hoped for c++ what has become c#. Well now i use c# with c if i need the speed
Maybe it's time for C++ community to create maintenance releases of old standards?
Not new features necessarily, but fixes or backports that fix major flaws.
It can also complement old standards. If a C++23 feature can be supported in C++98 or C++11, it should go to that standard with an update.
How would that even work? Implementations that’s been compliant for years suddenly become non-compliant?
Honest question.
If I want to spin up a new project with a coding agent to explore some idea and I'd like the bare metal performance, why would I choose C++ over Rust?
I could choose TypeScript over Rust if I wanted it to be html first or I could choose Go if I wanted it to be clear of the complexity of memory management or I could choose C# if I wanted it to have best interface with windows stuff or I could choose something Erlang VM based for resilience and multithreading.
But what reason might I have to pick C++?
Maybe you don't. If you were to spin up a new project with a coding agent most of the subsequent highlights of the languages you cited might also not matter.
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?
Maybe my reading comprehension has just nosedived but I could not find where this article discusses what the heck Contracts refers to?
You'll find plenty of info if you search for anything like "c++ contracts" [0], but the short of it is that they're just pre/post conditions on functions. Slightly improved assertions, basically.
[0] https://en.cppreference.com/cpp/language/contracts
https://www.cppstories.com/2026/cpp26_contracts/ is IMO a better introduction.
cppreference is often a bit too technical for its own good :)
But I think there's a broader issue which is that if it took me multiple searches to find a good-enough visual "pitch" for what contracts look like in practice, its champions have not yet won hearts and minds - which brings us to the situation at hand.
Oh im not a c++ guy but that actually looks pretty awesome because it’s like Hoare logic
Its a very inside baseball article. Contracts is a proposed C++ language feature for improving programmable assertions of program state. E.g. a better c++ version of C's assert function. That in theory will improve both safety and performance by letting people add more complex assertions (e.g. pre/post conditions) to functions.
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.
> How is the alternative called in C++?
what is it though? vcpkgs/decentralized repositories?
It is de facto vcpkg
With package managers on Linux, BSD and Haiku, the only odd man out needing packages is Windows, and vcpkg fills this gap so its no longer an issue.
Why would anyone want to rewrite anything in C++ given they can choose anything else? Like Rust or Go or C or Zig or literally anything else.
Compiler stuff in MLIR.
I wouldn't choose Rust because of compile times. C++ ones aren't great either, but with discipline in how you structure headers, you can get reasonable compile speeds. Unsafe Rust is also a bit of a PITA, and I have cases where I care lot about precisely how memory is laid out and accessed, I'd have to resort to it quite a lot. I don't love crates either, they smell a bit like node_modules and all big Rust projects I've seen have hundreds of them. Most C++ libraries are self contained, by nature of not having an easy way to declare dependencies.
I wouldn't choose Go because GC is a non-starter.
I wouldn't choose C because it's nice to have some form of generics or metaprogramming, even if templates are not exactly fantastic.
I wouldn't choose Zig because the language isn't stable, and the lead developer has hinted that they'll drop LLVM down the line, and I don't want to beta test their compiler backend.
Because, used sensibly, C++ is a better C. This is more or less what C++98 was, and even that is probably too much.
I think Rust's saftey guarantees are an important reason to throw it at LLMs. LLMs make stupid mistakes, even the very best ones, and a lot of them, all the time. Having a compiler reject those mistakes makes for a better automated process. C++ has some safety mechanisms as well, but they're weak and fragile compared to Rust.
For people with C++ experience working together months at a time that doesn't have to be a problem, but AI rewrites turn a million lines of one language into a million of the other in a day, followed by an impossibly short human review.
Rust also isn't as safe and correct as you'd hope it to be for "fuck it, let the LLM deal with it" style programming, but it's got the best speed-usability-safety balance out of the common languages if you don't trust your programmers.
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?
Memory safety was solved in 1959 with the invention of lisp
The issue that caused this to be voted down is often seen as a memory safety solution (not something I personally 100% agree with, but thats a broad view). And the rest of this release includes other memory safety work. And it was voted down and delayed for apparent political reasons (again not a view I agree with).
So most people will read your view as hypocritical/misinformed.
It could also be read as a straight up attack. Basically, a way of saying “why not follow Rust“ without having to say the word Rust.
I think it was a fair question. As someone who doesn’t follow C++ I really don’t know what else was in the proposal. It’s nice to hear there is memory safety stuff.
The memory-safety-relevant parts of the proposal could be salvaged without keeping contracts more broadly, by saying that the relevant behaviors (like indexing past the end of a std::vector) cause program termination in hardened builds. I'm sure it's more complicated than this but I don't think much more.
More generally, the C++ committee has had a really hard time agreeing on memory-safety stuff because there are a lot of different constituencies with completely different priorities (especially whether they're using it for greenfield vs. legacy vs. something in between), and the incentive is to make proposals sound good to everyone at the expense of actually being coherent.
- 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++?
you know downvoting without explaining why is part of herd mentality. i expected better on HN. dont you wanna give some reasons as to why you find this offensive?
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?
Your Rust very likely runs in a C / C++ environment.
99.9% of all system code in the world is still written in C/++. It runs your Java, C#, Javascript, Python, PHP, basically every production language that isn't Go or Rust. It runs the two most popular game engines in the world. It runs your phone, server, and laptop, no matter which of any you use. It runs your car. It runs almost every embedded and industrial application on the planet.
Is it still relevant, JFC. The way people on this forum manage to sequester themselves from reality. Let me reverse the question: is Rust relevant? Mozilla developed Rust, abandoned their Rust browser, and only 10% of Firefox is written in Rust. Maybe 1% of modules in Chrome and Linux are written in Rust, if that. And what of Rust applications written from scratch? Can you name ten applications that have, say, exposure to more than 100,000 users? Impossible mode: they can't be developer tools only used by other developers (uv, ripgrep, etc.), they must actually be applications used by enterprises or consumers.
As a big c++ fan, new projects are generally choosing Rust, which I would agree with, even though I do indeed love C++
I read that as "is c++ still relevant for new features, given Rust and its popularity", not "who is still using C++".
Personally, I think it is still relevant. Many people thought Kotlin could overtake Java, Java reinvented itself with new initiatives/features and was saved from becoming irrelevant.
Rust also has the LLM advantage which is where I think the "if it compiles it works" nature of Rust is easier for manual changes and maintenance when needed.
Java vs. Kotlin is a different matter. It's still an open question if C++ even could match Rust's features, not to say if it (the committee) wants to, and the answer seems to be "no".
> basically every production language that isn't Go or Rust.
Even in their case. Rust depends on LLVM which is wriiten in C++. Go needs libc on some platforms.
C++ is the third most popular programming language according to TIOBE behind C and python. It's got an 8.87% ranking. So yes it looks like C++ is still relevant. In fact C++ usage has risen slightly.
Rust is in tenth place with 1.44% ranking, it's rising fast but still has a long way to go before it catches C++.
I'm not going to speculate about why Rust hasn't yet supplanted C++ but I will say I don't find it surprising.
TIOBE is nonsense.
But, of course, there is still a lot of new C++ code written, more than Rust. I believe C++ will become legacy, but it's not there yet and even once that happens it'll take at least decades to stop writing C++.
Please for God's sake stop citing TIOBE.
A much more accurate snapshot would be Github - they recently published the top langauges for the year (so far, up til Sept 2026) by distinct monthly contributors and C++ comes in at 9 out of the top 10, and Rust doesn't even place in the top 10 yet, so yes it is highly relevant and prevalent, but not because TIOBE said so.
But, TypeScript, Python and Rust are the fastest growing languages, in that order, so also you cannot discount Rust.
https://github.blog/news-insights/octoverse/octoverse-commit...
You didn't mention why people shouldn't cite TIOBE so I checked. It's because they measure search engine queries to assess popularity. GitHub measures actual code usage in real repos.
I agree the GitHub methodology seems better. I don't think TIOBE methods mean that it's ranking is completely irrelevant but it'll be noisy and you could easily game it.
Even if C++ is irrelevant for new code, there's so much software already written in it that we'll be maintaining it for decades to come. I'd argue that Cobol and Fortran have been mostly obsolete for new code for almost 30 years now, yet both are still widely used today, and they've even had major updates in the past decade [0] [1]. And there's even more software written in C++ than there is in Cobol or Fortran, so I don't think that C++ is going away any time soon.
[0]: https://en.wikipedia.org/wiki/COBOL#COBOL_2023
[1]: https://en.wikipedia.org/wiki/Fortran#Fortran_2023
with ai their future seems very uncertain. ports are now very easy, so languages have to stand in their own merits
Essentially all high-end systems code for high-performance and high-reliability systems is still written in modern C++. That language has many attractive properties, including safety features that Rust does not currently support.
Additionally, for pure performance requirements, C++ is still materially faster than Rust in practice. That may change some day. C++ has many issues but it is also objectively excellent at many things.
> That language has many attractive properties, including safety features that Rust does not currently support.
Could you expand on what specific safety features C++ has that Rust doesn't?
> Is C++ still relevant? What prevents Rust from completely supplanting it?
A highly mature ecosystem with well-established libraries. Especially in certain fields (DSP, robotics, CAD kernels, microcontrollers, etc.), there are no equivalent libraries and frameworks in Rust with such a proven track record.
Now, LLMs can rewrite those libraries in Rust quite easily. Such options weren't available a few years back. But it's still hard to prove that a rewrite hasn't introduced new bugs. It's easy to demonstrate that a piece of code has bugs, but much harder to prove that it doesn't introduce any new ones.
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.
Perhaps it is, in this case it would be between money and everyone else specifically. Contracts is a pet project of Microsoft and the heavy money parts of the committee. They've basically shouted down the dissenters, hence the effectively unprecedented action of the rubberstamp portion of the process saying they dont think consensus was reached in a kosher way.
No one who developed contracts works for Microsoft. Of the like 20 people who contributed to the feature, 4 of them work for Bloomberg, so you could maybe argue that Bloomberg has a vested interest in the feature, but that's really stretching things.
Support for contracts is fairly broad and spans numerous organizations.
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.
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.
A lot of folks, many of them our most capable programmers, are fighting the last war. It’s like they think AI is going away and we’ll all work like it’s 2019 again.
Not to defend the particular proposal at issue here, but my sense is that contract-like things synergize quite well with AI coding, for the same reasons automated tests and static types do.
> So it's time to rethink.
>
> And we have no idea what AI systems will be doing in 2027.
How would you begin to form a plan of how you'll rethink if you can't even see into next year? Isn't it beneficial not to change the languages too much because there's so much training data for the current revisions? AI does not need to be catered to, that is the whole point and why it is useful.
We're going to need languages which both humans and AIs can read and write. We don't know what those look like yet. Contracts aren't a bad idea, but C++ has just become too big. Even people who used to be C++ language lawyers have said that.
Okay.
Wow. I’m surprised at the amount of downvotes. Are people really that in denial?