Recently, a C++ committee meeting happened in Wroclaw. The safety study group (SG23) spent almost three days processing papers, and in this discussion,

The growing interest in C++ safety is caused by the frequent classification of C++ among memory-unsafe programming language, as expressed in multiple official documents from different US agencies^1,2,3. The latter, in particular, introduces a sort of deadline: “For existing products that are written in memory-unsafe languages, not having a published memory safety roadmap by January 1, 2026 is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.”.

Within SG23 the discussion were mainly two camps.

The first (profiles) aims to make C++ safer than it currently is: it’s sustained by two authors, but they have declared the intention to merge their points of view. They both want to introduce “safety profiles”, that are optional levels of security which can be used to enable in extra checks, reduce functionality to safe subset(s), and in general have “better behaved” code. It’s composed of multiple papers^4,5,6,7,8. The general feeling is that this can get into C++26 in time, if we push enough (and both authors are committed to work on their proposals, and to put a considerable effort to merge them).

The second camp (“Safe C++”) builds on the existing experience of Circle, and aims to a higher goal: making C++ as safe as Rust, by adding a new mechanism very similar, if not identical, to Rust’s borrow checker⁹ (I’m not an expert in Rust or its borrow checker, so I cannot highlight the differences, but my understanding is they’re very similar). This came with a long list of language enhancements, and a brand-new standard library too. This isn’t something we can easily make happen by C++26, and even the C++29 timeline is going to be tight.

My feeling is that, on both side, there was an implicit assumption, that the other side wasn’t fixing the problem, and, to a degree, i sympathize for both.

The Profiles proposals are applying changes that are less radical, as they want to address one of the main concerns of safety as quickly as possible, allowing C++ users to just say “our safety path is to migrate to C++26 as quickly as possible”. My impression is that this is considered to be “too little” by some.

The “borrow checker” proposal requires a longer standardization path (it requires a number of language features, and a brand-new C++ standard library, which realistically won’t happen before C++29), and the fear is that would happen “too late”.

The final poll was, in my opinion, a bit odd: we were asked to prioritize one, the other, none, or, more confusingly, both proposals. The latter choice confused me because, in my mind, that solution would have been a strong risk of doing “too little, too late”.

I ended up voting to prioritize for the Profiles proposal, but what I really wanted to express is that we need a Safer C++ now, and we can have the Safest C++ later. My hope is that Profiles will give us a temporary solution to respect some of the requirements of the US bills, and buy us some time to add the borrow checker later (this will also requires to have a new standard library, which comes with extra benefits, as this could enable us to review some legacy decisions and apply improvements on some parts of our standard library – it’s not something we want to rush).

1. 2023-04 – National Security Agency – Cybersecurity Information Sheet – Software Memory Safety ↩︎
2. 2024-02 – The White House – Back to the building blocks: A path toward secure and measurable software ↩︎
3. 2024-10 – America’s Cyber Defence Agency – Joint guide: Product security bad practices ↩︎
4. 2024-05 – Bjarne Stroustrup – A framework for Profiles development (P3274R0) ↩︎
5. 2024-10 – Herb Sutter – Core safety Profiles: Specification, adoptability, and impact (P3081R0) ↩︎
6. 2024-10 – Herb Sutter – Strategy for removing safety-related undefined behavior by default (P3436R0) ↩︎
7. 2024-10 – Bjarne Stroustrup – Profile invalidation – eliminating dangling pointers (P3446R0) ↩︎
8. 2024-10 – Bjarne Stroustrup – Profiles Syntax (P3447R0) ↩︎
9. 2024-09 – Sean Baxter, Christian Mazakas – Safe C++ (P3390R0) ↩︎