C++ Is Getting A Borrow Checker

C++ is moving toward a “safe subset” model—aiming to deliver Rust-like memory safety without abandoning C++’s existing ecosystem. A new proposal for “safe C++” would prohibit undefined behavior inside explicitly marked safe regions, require developers to opt out into unsafe code for operations that can’t be proven safe, and introduce a borrow-checking workflow similar to Rust’s. The practical goal is to let organizations keep writing C++ while reducing the most dangerous classes of bugs: use-after-free, uninitialized reads, and certain data-race hazards.

The proposal’s core mechanism is a feature-flagged extension of C++ that remains backward compatible: existing code should still compile normally, and safety checks only activate when developers choose the new model. Under the hood, the compiler lowers safe functions into an intermediate representation and then performs borrow checking on that form. A new `safe` modifier marks safe scopes, while an `unsafe` keyword gates pointer operations and other operations that can violate the safety guarantees. In effect, old C++ code is treated as unsafe by default, so developers would wrap unsafe operations inside clearly delimited blocks rather than mixing them invisibly throughout a program.

Safety is defined in categories. Lifetime safety targets uninitialized-variable bugs and use-after-free. Borrow checking is used to prevent invalid aliasing and to support a “destructive move”/relocation concept—once a value is moved, it can’t be used again. Type safety focuses on null-related hazards and other invalid states, with the proposal calling for safer alternatives such as choice/tagged union types when unions and raw pointers would otherwise be used. Runtime safety adds checks like bounds checking (for example, preventing out-of-range indexing) and other inserted protections, with the option to skip some checks in performance-critical paths.

Thread safety is also part of the plan, borrowing the Rust framing: types would be marked as safe to send across threads (`Send`) and safe to share between threads (`Sync`). The proposal suggests using concepts/constraints and interface-like queries to express these properties, so the compiler can reject unsafe cross-thread usage at compile time.

A major adoption question hangs over the proposal: rewriting existing C++ codebases is expensive, and Rust’s semantics differ enough from C++ that a full migration would require substantial developer retraining and code restructuring. The safe C++ approach tries to avoid that by extending C++ rather than replacing it. Still, the transcript repeatedly flags friction points—especially around interoperability with existing C and C++ libraries, the overhead of safety checks, and the complexity of the eventual syntax for safe references/borrows.

Even with those uncertainties, the direction is clear: safe C++ aims to make “accidental memory corruption” harder by construction, while preserving the ability to drop into unsafe code when necessary. The result would be a hybrid language model—C++ where safety is opt-in and enforced by compiler analysis, not just developer discipline.