One year ago, the Safe C++ proposal was made. The goal was to add a safe subset/context into C++ that would give strong guarantees (memory safety, type safety, thread safety) similar to what Rust provides, without breaking existing C++ code. It was an extension or superset of C++. The opt-in mechanism was to explicitly mark parts of the code that belong to the safe context. The authors even state:
Code in the safe context exhibits the same strong safety guarantees as code written in Rust.
The rest remains “unsafe” in the usual C++ sense. This means that existing code continues to work, while new or refactored parts can gain safety. For those who write Rust, Safe C++ has many similarities with Rust, sometimes with adjustments to fit C++’s design. Also, because C++ already has a huge base of “unsafe code”, Safe C++ has to provide mechanisms for mixing safe and unsafe, and for incremental migration. In that sense, all of Safe C++’s safe features are opt-in. Existing code compiles and works as before. Introducing safe context doesn’t break code that doesn’t use it.
The proposal caught my interest. It seemed like a good compromise to make C++ safe, although there were open or unresolved issues, which is completely normal for a draft proposal. For example, how error reporting for the borrow checker and lifetime errors would work, or how generic code and templates would interact with lifetime logic and safe/unsafe qualifiers. These are just some of the points, the proposal is very long and elaborate. Moreover, I am not a programming language designer, so there might be better alternatives.
Anyway, today I discovered that the proposal will no longer be pursued. When I thought about the proposal again this morning, I realized I hadn’t read any updates on it for some time. So I searched and found some answers on Reddit.
The response from Sean Baxter, one of the original authors of the Safe C++ proposal:
The Safety and Security working group voted to prioririze Profiles over Safe C++. Ask the Profiles people for an update. Safe C++ is not being continued.
And again:
The Rust safety model is unpopular with the committee. Further work on my end won’t change that. Profiles won the argument. All effort should go into getting Profile’s language for eliminating use-after-free bugs, data races, deadlocks and resource leaks into the Standard, so that developers can benefit from it.
So I went to read the documents related to Profiles[1][2][3][4]. I try to summarize what I understood: they are meant to define modes of C++ that impose constraints on how you use the language and library, in order to guarantee certain safety properties. They are primarily compile-time constraints, though in practice some checks may be implemented using library facilities that add limited runtime overhead. Instead of introducing entirely new language constructs, profiles mostly restrict existing features and usages. The idea is that you can enable a profile, and any code using it agrees to follow the restrictions. If you don’t enable it, things work as before. So it’s backwards-compatible.
Profiles seem less radical and more adoptable, a safer-by-default C++ without forcing the Rust model that aims to tackle the most common C++ pitfalls. I think Safe C++ was more ambitious: introducing new syntax, type qualifiers, safe vs unsafe contexts, etc. Some in the committee felt that was too heavy, and Profiles are seen as a more pragmatic path. The main objection is obvious: one could say that Profiles restrict less than what Safe C++ aimed to provide.
Reading comments here and there, there is visible resistance in the community toward adopting the Rust model, and from a certain point of view, I understand it. If you want to write like Rust, just write Rust. Historically, C++ is a language that has often taken features from other worlds and integrated them into itself. In this case, I think that safety subsets of C++ already exist informally somehow. Profiles are an attempt to standardize and unify something that already exists in practice. Technically, they don’t add new fundamental semantics. Instead, they provide constraints, obligations and guarantees.
In my opinion, considering the preferences of the committee and the entire C++ community, although I appreciated the Safe C++ proposal and was looking forward to seeing concrete results, considering the C++ context I believe that standardizing and integrating the Profiles as proposed is a much more realistic approach. Profiles might not be perfect, but they are better than nothing. They will likely be uneven in enforcement and weaker than Safe C++ in principle. They won’t give us silver-bullet guarantees, but they are a realistic path forward.
[1] Core safety profiles for C++26