Safe C++ proposal is not being continued

Status: Safe C++ vs Profiles

  • The specific “Safe C++” proposal is abandoned; the committee is instead pursuing “Profiles” (restricted subsets of C++) as its safety path.
  • Several commenters argue the title is slightly misleading because work on safety continues, but in a very different and much weaker form than Safe C++.
  • Profiles are widely viewed as only a small step beyond existing compiler flags, sanitizers, and linters, not a Rust‑class safety model.

Perceived Limits of Profiles and Static Analysis

  • Critics say Profiles mostly “delete” unsafe constructs without providing the language machinery (lifetimes as types, ownership, borrowing) needed to express and check real invariants, especially for non‑owning references.
  • There’s skepticism that purely local/static analysis over today’s C++ (without new annotations or types) can soundly infer aliasing and lifetimes; examples like std::sort and iterator invalidation are cited as fundamentally unsafe.
  • Some argue the standard library itself is too unsafe for any meaningful safe subset, absent a new “std2” designed for safety.
  • Others think Profiles are explicitly scoped as “good enough” heuristics, not formal guarantees; that may help optics (e.g., with regulators), but not deliver true memory safety.

Rust and Other Alternatives

  • Many see Rust as the only credible route to strong memory and concurrency safety, via borrow checking and Send/Sync, even though it sometimes forces redesign and can be painful to learn.
  • Some lament the loss of C++’s powerful template metaprogramming and would prefer a “Safe C++” fork or Rust‑like subset over a full language switch.
  • D, Go, Swift, Java, Zig, and hardware protections are mentioned as partial answers; D’s safety features are praised but its ecosystem and adoption are seen as insufficient.

Culture, Governance, and Trajectory

  • A recurring theme is “safety culture”: Rust is seen as having it; C++ (and its committee) largely does not.
  • Committee decisions (killing Safe C++, doubling down on Profiles, past missteps like export and modules) are interpreted as prioritizing backward compatibility, performance folklore, and politics over safety.
  • Some predict C++ will increasingly become a legacy language (like modern Fortran): still updated, widely used in old code, but losing mindshare for new projects to safer ecosystems.

Practical Safety Today

  • Many teams already rely on sanitizers, static analysis, and stricter coding guidelines; this is seen as necessary but insufficient for Rust‑level guarantees.
  • There is disagreement on whether memory bugs (especially use‑after‑free) remain dominant in practice or are now largely mitigated by tooling.