Document: P3970R0
Authors: David Vandevoorde, Jeff Garland, Paul E. McKenney, Roger Orr, Bjarne Stroustrup, Michael Wong
Date: 2026-01-16
Audience: EWG, SG12, SG20, SG23
Directions Group statement on safety profiles. The paper argues that SG23 and EWG have repeatedly pointed to Profiles as the direction, but the committee faces "a stream of uncoordinated proposals" not aligned with the framework. Calls on implementers to coordinate on framework support, proposes initial profiles (initialization, ranges, resources, education), and identifies harder targets (invalidation, arithmetic, concurrency). Notes an experimental implementation in a major compiler.
Reminder: be civil. The paper authors sometimes read these threads. Rule 2.
Profiles were introduced to EWG in 2023. It is now 2026. The paper says there is "a specification and an experimental implementation is being conducted in a major C++ compiler." Unnamed. One compiler. Experimental. Three years of "this is the direction" and the deliverable is an unnamed experiment.
Meanwhile the paper tells other proposals to stop being "uncoordinated." Maybe the coordination should come with an implementation people can try.
The framework paper exists. The implementation guide is being written. Compiler work is happening. The DG is asking for more implementations, not claiming the work is done. "Call to action" is literally the title. The action hasn't happened yet. That's the point of the call.
If the framework needs implementers to volunteer, maybe it should come with enough detail that they can start. The paper asks organizations with money and expertise to build it. That's not a technical specification. That's a fundraising pitch.
Rust shipped memory safety in 2015. It's 2026. C++ is still publishing calls to action about maybe getting initialization checking if someone volunteers to implement it.
Rust started from scratch. C++ has billions of lines of existing code that can't be rewritten. Making an existing language safer without breaking the existing codebase is a harder problem than designing a safe language from nothing. Both are achievements. They're not the same achievement.
The billions of lines aren't going to opt into profiles either. When's the last time your company turned on a new warning flag across the entire codebase?
New code can opt in. That's the point. Profile-clean new code interfacing with legacy code through well-defined boundaries. You don't boil the ocean. You build safe islands.
The initial profiles list is pragmatic. Initialization first - because nothing else works if you're reading uninitialized memory. Ranges second - because buffer overflows are the number one CVE category. Resources third - RAII enforcement. Education fourth - keep beginners out of dark corners.
These are achievable. The harder ones (invalidation, arithmetic) are flagged as requiring "serious static analysis." Honest about what's easy and what's hard. I respect that.
The invalidation profile is the one people actually want. "No access through dangling pointers" is the guarantee that would change how C++ is perceived by the security community. And it's in the "hard, requires serious static analysis" bucket. The easy profiles are useful but they're not what the White House report is asking for.
Sean Baxter shipped Safe C++ in Circle with borrow checking, lifetime safety, and pattern matching. It works today. You can compile code with it. The DG paper mentions none of this. The "uncoordinated proposals" complaint presumably includes his work. A working implementation being called "uncoordinated" because it doesn't use the Profiles framework is a choice.
Circle's approach adds new language features (borrow checker, lifetime annotations, safe references). Profiles operate within existing C++ - no new syntax, no new type system. They're different strategies. The DG is advocating for the one that doesn't require learning a new language.
One approach ships and works. The other is a call to action asking for volunteers. The committee can debate strategy. Users will adopt whichever one catches their bugs.
Stroustrup is an author. When the creator of the language co-signs a "call to action" on safety with five other DG members, the committee pays attention. Whether you think profiles are the right approach or not, this paper is going to shape the next three years of evolution work.
An "education" profile that enforces a restricted version of C++ for novices. Core Guidelines as the inspiration. SG20 interested. This could be genuinely useful - "student mode" that bans raw pointers, raw new/delete, C-style casts, and half the footguns that make C++ hard to teach. Or it could be a moving target that never converges.
Teaching C++ would be radically different if I could tell students "compile with
-profile=educationand the compiler won't let you make the mistakes I'm about to spend two weeks explaining." The question is what goes in and what stays out. Every instructor will have a different opinion.The "subset-of-superset strategy" means profiles restrict what you can write (subset) while the language keeps growing (superset). The problem: every new feature that isn't profile-aware becomes a hole. Coroutines, modules, consteval, reflection - each needs profile integration. That's a perpetual maintenance burden on every profile as the language evolves.
New features default to profile-compatible unless they introduce new unsafety. Coroutines don't add new pointer dangling that doesn't already exist. Modules are safer by default (no macro leakage). The maintenance burden is real but it's proportional to how much unsafety the committee adds, which is exactly the pressure profiles are designed to create.
The elephant in the room: lifetime safety (the invalidation profile) requires whole-program analysis or very conservative local analysis. Clang's lifetime warnings already exist and they're useful but limited. The paper acknowledges this is "not ideal as part of initial implementation experiments." Translation: the hard safety guarantee everyone wants is years away even after the framework ships.
[removed by moderator]
Something about Bjarne being out of touch. You know the drill.
Rule 2. Take a breath.
The US government, the EU, and multiple national cybersecurity agencies have published guidance recommending memory-safe languages. C++ is on the "not recommended" list. Profiles are the committee's answer to that pressure. Whether they're technically the right answer matters less than whether they ship before the procurement guidelines harden.
"We encourage implementers to coordinate and if possible collaborate to avoid inessential incompatibilities." I work on a major compiler. We haven't been contacted. The coordination the paper calls for would be welcome. The paper calling for it isn't the same as it happening.
The "resources" profile is literally just RAII enforcement. Every C++ style guide already says this. Every linter already checks for it. Making it a profile is formalizing what we've been doing for 20 years. Not exciting. But necessary if profiles are going to cover the basics first.
The ranges profile is interesting because it connects hardened standard library implementations (which already exist in libc++ and libstdc++) with compile-time prevention of raw pointer subscripting. You get both runtime bounds checking from the library AND compile-time rejection of
ptr[i]. That's a meaningful safety improvement.Is a DG statement a direction or a mandate? The paper says "we face a stream of uncoordinated proposals" and calls for building "on the proposed Profiles framework." If someone brings a safety proposal that doesn't use profiles, does EWG now have political cover to reject it regardless of technical merit?
DG statements are advisory. EWG can and does ignore them when the room disagrees. But a DG statement signed by Stroustrup, Vandevoorde, and McKenney carries weight. It's a strong signal, not a rule.
The arithmetic profile: no implicit narrowing conversions, no overflow or underflow. Straightforward to specify. Brutal to enforce on existing codebases. Every
int x = some_longis a violation. Everyunsigned - unsignedthat wraps is a violation. This is the profile that will generate the most "false positive" complaints.In automotive and aerospace, MISRA already enforces a restricted subset of C++. Profiles could standardize what MISRA does ad-hoc. If a profile for safety-critical systems aligns with MISRA, we'd have one set of rules instead of two. That alone would be worth the effort.
This is easy to miss. Profiles are a framework, not just a safety feature. Style profiles, performance profiles, ABI-compatible profiles. The framework is more general than the safety conversation implies.
This is the most important sentence in the paper and it's the last one. If profiles ship only in proprietary toolchains, adoption will be slow and fragmented. Open source implementations are how C++ features actually reach developers.
"After that, more profiles should be defined and implemented, notably a concurrency profile." Data races are the other half of the safety story. Initialization and bounds checking are necessary but a concurrency profile would be transformative. That said, statically checking for data races in C++ is... ambitious.
Three years of "profiles are the direction." Zero profiles shipped. The NSA publishes another guidance document. The EU adds C++ to its "use with caution" list. And we publish another call to action. At what point does the call to action become a call to panic?
*nervously glances at the 200
-Wno-flags in my CMakeLists.txt*[removed by moderator]
committee gonna committee