I recently watched the c++ documentary and it was super sobering in how it mirrors this description of the process. https://herbsutter.com/2026/06/04/c-the-documentary-released...

The true goal of C++ is the self-preservation and funding of the ISO Committee specification “engine”, while compilers are merely an accidental by-product.

Once you see this then suddenly a lot of odd behavior makes sense. For example the committee can’t break ABI because then the old companies wouldn’t fund the new c++ standard, but would fund a committee that maintains/forks the old thing. The complexity / bureaucracy also provides jobs for those involved in many ways including writing new books every year and or consulting.

While end consumers might really care about compile speed, modularization, security, and all of the things modern languages give, that is secondary to keeping the committee alive.

Younger me would be like, oh no this is horrible someone will fix this! Older me is more sober and understands that once a system is up and running it will continue as is (this being an example of Pournelle’s Iron Law of Bureaucracy). Security by the way of migrations to Rust is causing what the committee sees as the first real threat to its existence as its patrons start adopting more and more Rust. As a result the committee is proposing to break compatibility as a means to keep them around just a little longer. Note: Actually fixing the security issues is not important only giving enough for sponsors to not leave so we will see what actually happens.

Thanks for this! I vaguely knew most of it but it's great to hear more details.

I think that my misunderstanding here is because I thought that the vote in Croydon back in March was the last chance to veto things, but re-reading https://herbsutter.com/2026/03/29/c26-is-done-trip-report-ma...

> are now producing the final document to be sent out for its international approval ballot

So yeah, I guess in most cases this final ballot is a rubber stamp (not a bad thing, actually, I'd argue it's the way it should be) but maybe this time it is not.

> And I think each national body has a veto. (that is the vote has to be unanimous, but not sure here).

No veto. Every P-member has a vote (abstain/approve/disapprove). Whether C++26 gets published is decided by numerical consensus.

This does sound a lot like there's a real risk of C++ imploding, in some form or another. (Arguably, it has been in that state for a while now.)

I personally agree that contracts probably shouldn't be in the standard, but this whole situation looks like a mess.

> The current contracts are not good enough for anybody who wants them -

This is a recurring pattern across large changes to c++. Modules and coroutines both are great examples of this.

> but it is good enough that they can start figuring out the details of making all the different factions happy.

I don’t think there’s really a plan to make the factions happy, there’s a plan to get X in, say it’s in and then ignore any actual criticism in favor of “it was the best we could do” while pointing at the other groups for not accepting the massive flaws.

> compile time abstract base class would enable compile time resolution of virtuals. so then i can do compile-time polymorphism

What's wrong with static polymorphism that have been around for at least 31 years? (1995 per [1]). Also know as CRTP [2] Apart, of course, from ugly verbose compilation errors...

And now c++23 "deducing `this`" [3,4] modern replacement which is supposed to improve compilation time and remove the verbose errors.

[1] https://www.artima.com/articles/the-most-important-c-non-boo...

[2] https://en.cppreference.com/cpp/language/crtp

[3] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p08...

[4] https://devblogs.microsoft.com/cppblog/cpp23-deducing-this/

Yeah, I heard spark was used on a small component in the nvidia gpu firmware so others seemingly agree. I'm mainly in the user mode driver space so my ideas have been around having a kernel mode driver that (assuming a correctly functioning pc) can't crash and user mode drivers that can't be exploited (at least in the rop chain sense). I'm kind of picking ideas from other languages that I like zig's error handling, ada's contracts, rust's lifetimes (hopefully soon to be replaced with more contracts instead), and things like how you can use "gas" in lean to prove a loops will terminate. I'm mainly building it up with AI right now for experimentation, but I also can't really trust it to be correct either because of using AI. Once I settle on the syntax more and pump out a lot more tests, I'm probably going to rewrite the compiler by hand (hopefully in the custom language itself.)

Contracts are written such that the compiler can diagnose a detected violation if it wants to. However most contracts realistically need whole program analysis to diagnose and no compiler can do that - you want a separate static analysis for that. (this doesn't exist, but there is hope people start writing those)

How would this allow compile-time resolution of virtuals that was not possible before?

Gcc can already do link-time devirtualization in some cases.

You might want to take a look at Real-time C++: Efficient Object-oriented and Template Microcontroller Programming by Christopher Kormanyos for some ideas.

Also take a look at David Crocker's Escher Technologies "Escher C Verifier and Escher C++ Verifier" (https://www.eschertech.com/products/ecv.php) and articles on "Verified Design-By-Contract" etc. linked to in my comment chain here - https://news.ycombinator.com/item?id=48544022

Suppose your function doodle_widget is supposed to take a Gonzo Widget, but you're worried somebody might call it with a Non-Gonzo Widget and that can't work.

Traditionally you write code which checks the Widget to see if it's Gonzo and if not you throw an exception. Callers can pick, for this function in particular, whether to handle the Exception, in which case they get that Exception to look at, or they can "bubble it up" to be handled in their caller, and so on all the way to the top of the program where if it bubbles up it's reported and then exits the program.

With Contracts you write a contract for the function with a pre-condition that the Widget is Gonzo. Your users (programmers who might call doodle_widget) can pick: If they fail a contract the program exits immediately reporting a violation ("quick enforce"), it reports the violation via a global contract handler and then exits ("enforce") or it just reports to the handler but doesn't exit ("observe") or finally, they ignore it entirely ("ignore")

These just aren't that different. The contract is maybe slightly better because of the enhanced semantic discovery - you could imagine tooling which gives you a yellow squiggly line because your code violates a contract requirement for example, it's definitely not practical to check exception raising that way.