C++26 Disapproved (andreasfertig.com)

154 pointsby thatxliner5 hours ago62 comments

jandrewrogers an hour ago

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.

drivebyhooting an hour ago

Your comment just made me realize contracts is different from concepts (which are basically bounded genetics, right…?)

stingraycharles an hour ago

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.

rramadass an hour ago

Concepts are for Types at compile time while Contracts are for Values at runtime.

jandrewrogers an hour ago

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 nuanced 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.

AlotOfReading 36 minutes ago

    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?

[0] https://www.youtube.com/watch?v=yhhSW-FSWkE

jandrewrogers 30 minutes ago

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.

amluto 5 minutes ago

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.)

YuechenLi 19 minutes ago

A concept is a compile time requirement that bounds templates which are the generics in C++, so you are close.

quotemstr an hour ago

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.

rramadass an hour ago

Absolutely Right! - https://news.ycombinator.com/item?id=50361435

jandrewrogers 44 minutes ago

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.

taybin 29 minutes ago

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.

LugosFergus 2 hours ago

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.

airstrafer an hour ago

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.

kllrnohj 15 minutes ago

I think you're confusing it with Concepts. Contracts are basically just asserts, nothing to do with templates.

skrrtww 2 hours ago

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.

Krutonium an hour ago

Maybe a slightly faster std::regex or whatever it's called; apparently it's horrendously slow for no benefit.

stingraycharles an hour ago

Ranges need work as well, there’s lot of opportunity to improve things there.

ameliaquining 27 minutes ago

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.

imaginit an hour ago

> 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.

lowatt 9 minutes ago

> 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?

nukanse an hour ago

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

jandrewrogers 39 minutes ago

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.

zamadatix 21 minutes ago

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.

jandrewrogers 8 minutes ago

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.

bajard 14 minutes ago

That's why it needs a lot of work. Writing SIMD in c++ is like writing assembly.

wahern an hour ago

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.

Maxatar an hour ago

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.

adzm an hour ago

So is he a hero, or villain? Does it all come down to concepts?

afdbcreid 26 minutes ago

Not concepts, contracts.

zugi 33 minutes ago

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.

aldanor 44 minutes ago

Approval of runtime failures essentially failed at runtime

jdw64 18 minutes ago

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?

hankbond 2 hours ago

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

AlotOfReading 2 hours ago

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

btown an hour ago

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.

bionhoward an hour ago

Oh im not a c++ guy but that actually looks pretty awesome because it’s like Hoare logic

SolarNet 2 hours ago

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.

ranger_danger 2 hours ago

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?

GalaxyNova 2 hours ago

Memory safety was solved in 1959 with the invention of lisp

SolarNet 2 hours ago

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.

MBCook an hour ago

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.

vivzkestrel 2 hours ago

- since you are a part of the voting group, i have a doubt

- let us say tomorrow everyone were to consider removing all unsigned variables across c++

- what is the impact in terms of compatibility for all the old c++ applications which i believe would be millions of them if not billions?

- the reason i ask is they say do not unsigned anything as much as you can because overflowing the bottom below 0 is easy

- has there ever been any consideration to get rid of unsigned xyz in c++?

voakbasda 2 hours ago

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.

SolarNet 2 hours ago

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.

Maxatar 2 hours ago

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.

SP3269 2 hours ago

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

drivebyhooting an hour ago

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?

willtemperley an hour ago

Your Rust very likely runs in a C / C++ environment.

anonymous908213 an hour ago

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.

adzm an hour ago

As a big c++ fan, new projects are generally choosing Rust, which I would agree with, even though I do indeed love C++

devsda an hour ago

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.

afdbcreid 26 minutes ago

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".

qtqtqt 44 minutes ago

> 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.

fancyfredbot an hour ago

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.

afdbcreid 28 minutes ago

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++.

gucci-on-fleek 40 minutes ago

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

jandrewrogers 22 minutes ago

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.

Animats an hour ago

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.

01100011 27 minutes ago

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.

ameliaquining 19 minutes ago

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.