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.
... continue reading