As the creator of C++, Stroustrup argues that opt-in Profiles — static rules enforced by the compiler — can harden the enormous existing C++ codebase without forcing rewrites. He contends that a Rust-style bolt-on would fracture the language, break decades of code, and still not ship in time to satisfy the regulators driving the urgency.
By submitting P4454R0 directly to Hacker News with its provocative title, acossta amplifies Stroustrup's framing that the committee is drifting away from the language's creator. The 99-point score and 84 comments suggest the submission resonated with developers sympathetic to preserving backward compatibility.
This camp, associated with Sean Baxter's Circle compiler, argues that only a borrow checker with lifetime annotations and a `safe` subset can deliver the provable memory safety regulators are demanding. They view Profiles as too weak to satisfy CISA, NSA, and EU CRA expectations, even if adoption requires breaking changes.
Stroustrup explicitly argues in the paper that WG21's tilt toward the Safe C++ camp is motivated less by technical merit than by a desire to be seen 'doing something' in response to CISA, NSA, and ONCD reports. He warns that this reactive posture will produce a worse language without actually meeting the 2026/2027 regulatory deadlines.
Bjarne Stroustrup, the creator of C++, has filed P4454R0 — a WG21 paper titled *"When a language's creator and its owners strongly disagree."* The title is not hyperbole. It is a formal, on-the-record statement that the person who invented C++ believes the ISO committee that governs it is heading somewhere he will not follow.
The immediate subject is memory safety. For the last two years, WG21 has been under direct pressure from the U.S. government (CISA, NSA, ONCD's 2024 memory-safety report) and the EU's Cyber Resilience Act to produce a credible answer to the fact that roughly 70% of CVEs in large C and C++ codebases are memory-safety bugs. Two camps formed inside the committee. Stroustrup's camp pushes Profiles: opt-in sets of static rules enforced by the compiler, designed to harden existing code in place without rewrites. The other camp — associated with Sean Baxter's Circle compiler and the "Safe C++" proposal — wants a Rust-style borrow checker grafted onto the language, with a new `safe` subset and lifetime annotations.
P4454R0 argues the committee has been quietly tilting toward the second camp, and that the tilt is driven less by engineering consensus than by the optics of being seen to "do something" about the government reports. Stroustrup's position, stated bluntly in the paper, is that a Rust-shaped bolt-on will fracture the language, break decades of code, and still not ship in time to matter to the regulators it is meant to appease.
Language-committee disputes are usually invisible to working developers. This one is not, because the stakes are no longer academic. The U.S. federal government has told agencies to produce memory-safety roadmaps by 2026, and the EU's Cyber Resilience Act starts imposing liability on shipped software in December 2027. Whatever C++ does in the next 18 months is what vendors will point to when regulators ask why they are still shipping it.
The technical disagreement is sharper than the usual "gradual vs. clean-slate" framing suggests. Profiles are cheap to adopt — you turn one on, the compiler flags violations, you fix or suppress them. The cost is that Profiles cannot prove absence of use-after-free in the general case; they catch patterns, not invariants. A borrow checker can prove it, but only for code written in its dialect, which in practice means a rewrite. Herb Sutter's cppfront and Baxter's Circle are both demonstrations that the second path is technically possible. Neither is a demonstration that the industry will actually take it.
Stroustrup's deeper argument, and the one worth reading the paper for, is about who C++ is for. His framing: C++ has roughly five million developers and tens of billions of lines of deployed code in kernels, trading systems, browsers, game engines, and embedded firmware. A safety story that requires any of those codebases to be rewritten in a new dialect is not a safety story — it is a migration story dressed up as one. The Rust community, he notes without naming it, solved safety by starting over. C++ cannot start over, and pretending it can is how you lose both the old users and the regulators.
The community reaction on Hacker News and r/cpp has split roughly along the lines you'd expect: systems programmers who already migrated performance-critical paths to Rust think Stroustrup is in denial; long-tenured C++ shops think Profiles are the only proposal that survives contact with a real codebase. What's new is the tone. Previous rounds of this debate (the Safe C++ paper in 2024, the Profiles TS last year) were technical. P4454R0 is political. Stroustrup names the dynamic and says, in effect, that if the committee votes for the borrow-checker path, he will say publicly that the language's creator does not endorse the direction.
If you ship C or C++ in anything the government buys, insures, or regulates — defense, medical, automotive, critical infrastructure, financial exchanges — you should stop treating this as committee gossip. The question your compliance team will ask in 2026 is not "is your code safe" but "what is your documented memory-safety plan," and "we're waiting for WG21" is going to stop being an acceptable answer.
Concretely, three decisions are worth making this quarter. First, turn on what you already have: `-fsanitize=address,undefined` in CI, `-Wlifetime` where your compiler supports it, and the Core Guidelines checker in clang-tidy. These are the de facto Profiles today, and they will be grandfathered into whatever ships. Second, inventory the code you'd actually rewrite if forced. Hot paths, parsers, anything touching untrusted input — if those are under 10% of your codebase, a Rust or Carbon interop story is cheaper than you think. If they're 50%, you need Profiles to work, and you have a stake in the committee outcome. Third, read P4454R0 itself. It's 20 pages, it's not written in standardese, and it is the clearest statement of the two competing futures you will get from a primary source.
For greenfield work, the calculus hasn't really moved. New systems-level projects are starting in Rust, Zig, or Go unless there's a specific C++ ecosystem lock-in (game engines, HFT, CUDA). This paper does not change that; it changes what you tell auditors about the code you already have.
The next WG21 meeting will decide whether Profiles or Safe C++ gets the committee's weight behind it, and Stroustrup has now made that vote a referendum on his own standing. Either outcome is bad for C++ as a political object: a Profiles win looks like the committee bowing to its founder, a Safe C++ win looks like the committee repudiating him. The language will keep shipping either way. But for the first time since the 1998 standard, the person who built it is telling you on the record that he doesn't think the people running it know what they're doing — and the regulators aren't going to wait for them to work it out.
Stroustrup's list of objections sounds quite sensible to me: https://www.stroustrup.com/Contracts_fundamental_flaws.pdf
This is a well-written and quite diplomatic summary by Herb Sutter. I'm not plugged in enough to be sure he's correct that Stroustrup's opposition was the main reason the C++26 vote failed where others have passed, but it sounds plausible.It also lists 6 possible paths forward for C++
As someone who spent a few weeks trying to get into C++ (pre-LLM, so maybe it's better now?) and kind of just gave up out of confusion, I really found it challenging to deal with the multiple different ways to do something. I mean, which pointer should I use? How should I iterate? I'm sure
I think this is putting too much weight on this event and Bjarne’s position on contracts.Bjarne’s opposition to contracts might have tipped the scale but there is definitely growing weariness (and wariness) about large half-baked features that are left as exercises to the implementors (looking at yo
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I haven't really paid attention to C++ in a while (last neat feature I saw was concepts). Usually I kind of enjoy the weird, expressive code golf you can write with the new features. For example I tried out using concepts to ensure Matrix dimensions were compatible with the desired operation. N