Safe C++ proposal all but abandoned in favor of profiles

The C++ standards committee appears to be moving away from a rigorously “Safe C++” subset and toward so‑called profiles, rekindling long‑running debates about how to make C++ memory safe without breaking the language or its ecosystem.

Safe C++ stalls as committee warms to profiles

Sean Baxter, co-author of the Safe C++ proposal, said in June that the Safety and Security working group voted to prioritize profiles over a dedicated safe subset. Baxter argues that the Rust-style model—built around strict, enforced safety boundaries—is unpopular within the committee and that “profiles won the argument.”

Safe C++ aimed to bring Rust-like guarantees—such as borrow checking to eliminate use-after-free and compile-time initialization analysis for type safety—directly to C++. Crucially, it was designed for incremental adoption: code could be written in a “safe context” while existing unsafe code would continue to run unchanged.

Is it really abandoned? It depends who you ask

Not everyone agrees that the effort is dead. Erich Keane, a C++ committee member and co-chair of the Evolution Working Group (EWG), characterized the most recent discussion as a split vote of encouragement: roughly 20 of 45 participants encouraged Baxter’s paper, while 30 of 45 favored work on profiles, with a handful neutral. Keane emphasized that Baxter is welcome to continue and that many on the committee support further exploration.

Baxter counters that there’s an irreconcilable design gap. He points to an EWG principle discouraging “safe” or “pure” annotations that would require safe functions to call only safe functions. In his view, this conflicts with the core of Rust’s model, which relies on strict function “coloring” to maintain safety guarantees.

Profiles: a different path to safety, but still contentious

Profiles propose a configurable set of guarantees that developers can opt into, with the toolchain enforcing chosen constraints. C++ creator Bjarne Stroustrup supports this direction, describing profiles as a way to say, “I want this set of guarantees and it will then be enforced.” He has also lamented that the committee did not ensure profiles would land in C++26.

However, profiles are hardly a consensus solution. Critics note they lack a proven, widely deployed implementation, did not make the C++26 cut earlier this year, and now require more design work. Skeptics worry profiles don’t look like an established practice and question whether they can deliver the level of safety many developers need.

Baxter’s critique: profiles won’t work—and the standard library is unsafe

Baxter has been blunt: if profiles were viable, he says, he would have built them. He points to concrete failure cases in an analysis posted here: https://www.circle-lang.org/draft-profiles.html. He also argues that the entire C++ Standard Library is “unsafe” by construction under rigorous safety criteria, and notes that his proposal for a new, strictly safe “std2” was rejected.

What it means for C++ developers

The upshot is a familiar stand-off: strong, uniform safety guarantees are hard to retrofit into a language as flexible and performance-focused as C++. Safe C++ would have imposed strict boundaries and compile-time checks; profiles aim to let users choose constraints, potentially easing adoption but raising questions about completeness, portability, and enforcement.

Meanwhile, teams under pressure to eliminate memory-safety bugs may continue to look elsewhere. Rust remains the most prominent alternative for new systems projects, while Google’s Carbon experiment—pitched as a C++ successor—targets a 1.0 release “beyond 2028,” leaving a long runway before it could be a practical replacement.

For now, developers seeking safer C++ have a patchwork of options: static analysis, sanitizers, guidelines like the C++ Core Guidelines, and selective use of safer abstractions. Whether profiles can evolve into a trustworthy, widely implemented solution—or whether a stricter Safe C++ model can regain momentum—remains unsettled. What’s clear is that memory safety is still the central question in C++ evolution, and the community has yet to agree on how far the language itself should go to enforce it.