The goal of the Safe C++ proposal is extending C++ by defining a superset of the language that can be used to write code with the strong safety guarantees similarly to code written in Rust. The key to its approach is introducing a new safe context where only a rigorously safe subset of C++ is allowed.
The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas, originates from the growing awareness that C++ memory unsafety lies at the root of a large part of vulnerabilities and memory exploits. The only existing safe language, say Baxter and Mazakas, is Rust, but their design differences limit interoperability, thus making it hard to migrate from one language to the other. For example, Rust lacks function overloading, templates, inheritance, and exceptions, while C++ lacks traits, relocation, and borrow checking.
Given this context, Safe C++ aims to provide a smoother path that ensures existing code can be compiled with no problem and users can opt it to the new safe language features to migrate existing code incrementally or write new code that work together with unsafe code.
Safe C++ developers are prohibited from writing operations that may result in lifetime safety, type safety or thread safety undefined behaviors. Sometimes these operations are prohibited by the compiler frontend, as is the case with pointer arithmetic. Sometimes the operations are prohibited by static analysis [...] The remainder of issues, like out-of-bounds array subscripts, are addressed with runtime panic and aborts.
One key aspect of the Safe C++ proposal is that its safe subset must remain useful, say their proponents. This means that if some C++ features like pointers and unions are removed, they must be replaced by equivalent, but safe alternatives that will also improve language expressiveness and developers' experience.
For example, the Safe C++ proposal includes pattern matching, choice types, and borrowing. To ensure thread-safety and minimize the risk of data races causing undefined behavior, Safe C++ adopts send and sync type traits similarly to what found in Rust.
The proposal also introduces explicit mutation for references, which is required by the borrowing system, and a model for object relocation, which is standard in Rust but unusual for C++ programmers who are used to manage raw pointers and legacy references tied to memory locations.
All of Safe C++ abstractions strive to honor C++ goal of providing zero-cost abstractions.
As a final note about Safe C++, it is worth noting its definition is not complete yet, since several design issues are still unresolved. Those include function parameter ownership, non-static member functions with lifetimes, and relocation out of references.
Safe C++ is not the only approach to change C++ and make it a safe, or at least safer language. InfoQ has recently covered another such proposal which is based on C++ profiles, a feature the ISO Committee is currently working on to deal with type safety, bounds safety, and lifetime safety.