This post and accompanying discussion detail the discontinuation of the "Safe C++" proposal, an ambitious effort to integrate Rust-like memory, type, and thread safety into C++ without breaking existing code. The C++ Safety and Security working group opted instead to prioritize "Profiles," a less radical approach that defines restrictive language subsets to achieve "good enough" safety via compile-time constraints.
The decision has sparked a significant debate within the C++ community. While some see Profiles as a pragmatic, incremental path to address common pitfalls, many critics express pessimism, arguing that Profiles are insufficient to provide true memory safety and are seen as a political "checkbox" solution rather than a fundamental language improvement. The discussion highlights a perceived "safety culture" problem within the C++ committee, the challenges of adopting Rust's strict model, the merits of alternative languages like D and Go, and the broader existential questions about C++'s future if it fails to address memory safety comprehensively.
Exploring C++ Safety: The Demise of "Safe C++" and the Rise of "Profiles"
September 13, 2025: "Safe C++" Proposal Discontinued
The "Safe C++" proposal, aiming to introduce a safe, Rust-like subset with strong memory, type, and thread safety guarantees into C++, will no longer be pursued.
The C++ Safety and Security working group prioritized "Profiles" instead, citing the "Rust safety model" as unpopular with the committee.
Goals of the "Safe C++" Proposal
Provide strong safety guarantees similar to Rust.
Maintain backwards compatibility by making safe contexts opt-in, allowing incremental migration of existing code.
Faced open issues regarding borrow checker error reporting and template interactions with lifetimes.
"Profiles": The Alternative Approach
Definition: Profiles aim to define modes of C++ that impose compile-time constraints on language and library usage to guarantee certain safety properties.
Mechanism: They primarily restrict existing features and usages, offering a backwards-compatible, "safer-by-default" C++ without forcing the Rust model.
Simone Bellavia (author) viewed Profiles as a less ambitious but more realistic path, albeit potentially weaker than Safe C++.
Key Criticisms and Concerns Regarding Profiles
Insufficient Safety: Many are pessimistic, arguing Profiles are "not very good" (tialaramex) and won't achieve the same level of safety as Rust or even guarantee full memory safety (steveklabnik).
Lack of Composition: Profiles may not compose effectively due to multiple, potentially arbitrary profiles (tialaramex).
"Vaporware" / "Checkbox" Solution: Some believe Profiles are a "magic solution" to enable C++ to check a box for government mandates (e.g., CISA's call for memory-safe languages) rather than a genuine safety improvement (jcranmer).
Implementation Challenges: Profiles are seen as potentially unimplementable or useless due to high false positives/negatives, with no real-world static analysis achieving comparable guarantees to Rust (dminik).
Performance Concerns: Widespread reference counting for lifetime safety, as one potential Profiles mechanism, is considered too expensive for the C++ committee (tialaramex).
No Tools for Safe Code: Profiles restrict usage but don't provide new language tools for writing safe code; the current standard library (stdlib) is seen as riddled with safety issues that can't be fixed due to backwards compatibility (dminik).
Broader C++ Committee & Community Perspectives
Safety Culture: C++ is perceived by some as lacking a strong safety culture (tialaramex), with the committee sometimes seen as disconnected from developers facing safety issues (AlotOfReading, IshKebab).
Committee Practices: Concerns exist that the committee designs features without sufficient implementation feedback, leading to flaws and "vaporware" (jcranmer, pjmlp).
Rust vs. C++:
Productivity: Rust shifts effort to an earlier development phase, potentially saving debugging time later (zozbot234), but some find it less productive due to borrow checker struggles and difficulties with inheritance (Animats).
Redesign: Rust sometimes requires program redesigns because programs are "flawed at some fundamental level" (Voultapher).
Memory Safety: Rust's reference safety (e.g., preventing use-after-free) is highlighted as a key advantage over C++ (Voultapher).
Alternative Languages:
D Language: Offers memory safety features like bounds-checked arrays, default initialization, and static pointer checks without requiring program redesigns; optional garbage collection provides full memory safety (WalterBright). However, it faces issues with GC acceptance, a fragmented standard library, and a smaller ecosystem (IshKebab, pjmlp).
Go Language: Proposed as a good compromise, offering safety at a minor performance cost with GC and "green threads" (Animats).
Types of Safety: Discussion covers spatial (buffer overflows), temporal (use-after-free), initialization, thread, and type safety (MForster).
Future of C++:
Some argue C++ will never be truly safe due to its C roots (flykespice).
Calls to continue "Safe C++" work outside the official committee are made (quotemstr).
Predictions range from C++ remaining relevant in niche fields with a "two-language" approach (pjmlp) to becoming irrelevant like Fortran if safety isn't addressed (quotemstr).
Specific Safety Initiatives
WebKit's internal efforts use libTooling and custom smart pointers to enforce stricter safety rules, preventing common bugs like use-after-free, even if not 100% comprehensive (favorited, pizlonator).