A proposed plan for profiles in C++

1 Abstract

This paper proposes a tentative plan for making progress on safety and profiles in C++. If adopted, this plan could allow SG23, EWG, and CWG to finalise the design and wording for profiles in time for inclusion of this feature in C++29.

2 Motivation

Profiles in C++ has been suggested over the past half decade, and been worked on in some way or another for a much longer time. In many polls the committee has indicated a strong desire to make C++ a safer language, and that the design intent of profiles are a great way to do it. However, there is insufficient agreed-on documentation available to WG21 to be able to say specifically what profiles can and cannot do, leading to confusion and inability of individuals and groups to make meaningful contributions to profiles.

This is a bad thing, as we know that C++ has been pushed since at least 2021 to become a more memory safe language, typically being lopped in with C. This is mostly undeserved, as unlike C, C++ offers many abstractions and abstraction techniques that prevent bugs, in many cases even using C++98 would allow one to prevent bugs that in some memory safe languages can only be mitigated. Much of what C++ has going for it is its generality, abstraction power and backward compatibility. This backward compatibility is in part why C++ keeps being coupled to C. Nearly any C code is valid C++ code, which imports any safety judgments about C programs verbatim into C++. As the ability to directly include C interfacing into C++ is one of its main benefits, it makes little sense for C++ to remove that entirely. At the same time, we're aware that many of the safety issues in C++ come either directly or indirectly from use of C-like constructs. The way to provide a path forward for C++ to become less unsafe and to prevent most of these problems is to remove the C-style constructs, while at the same time not removing them.

Profiles is the best way we know to do this. They provide a hook to indicate some code should either allow them, or not allow them. This provides a solution to the conundrum of both removing and not removing them - we specify the place where their use is allowed. Depending on the state of our code, we'll likely want to apply a profile in some restricted area, or exclude only a restricted area from a profile.

These last two paragraphs are riddled with generalities and vaguery. This is intentional, as we don't quite have on paper what profiles can and cannot do, and how some profiles would interact with others. In particular, we don't have an agreed-upon set of principles that describe what an acceptable or good profiles paper or proposal would need to do, or which things we prioritize over which others. Over the past few years we have seen multiple papers pass by that attempt to move profiles forward in some way (P3081R2, P3589R2, P3700R0, P3984R0), so far none successful. As of the last meeting in Croydon (March 2026), SG23 has picked up the lead on documenting and leading profiles. This is the moment to agree on a plan, to have a working draft we can keep updating, and for SG23 to work together to be able to have profiles in a shippable state by the 2029 CD.

3 The plan

Assuming that the relevant deadlines in the C++29 release cycle will be the same as they were for C++20, C++23 and C++26, the plan for getting profiles into C++29 can be derived more or less directly from those deadlines. This is the plan we propose:

For simplicity, this plan is organised using physical WG21 meetings as milestones. However, we expect that the majority of the work will actually happen in between those meetings. The progress of this work will be reviewed in teleconferences and on the reflector. Without agreement and understanding of the principles that we consider to be the reasoning for any concrete choices made, there will be endless debates about why some choices were made or specific disagreements. After the principal agreement on those we need to get agreement on the specifics covered in the profiles framework - how to scope which profile applies where, how profiles compose, and how to specify subsetting and runtime checks. After that we have a coherent profiles framework that is suitable to merge into the main IS, with sufficient concrete profiles specified to show how to add others in the future.

Ideally we are not starting this document and all discussions from empty. We have had many proposals in the past that have large amounts of what we need - up to the level of wording in some cases. We should take from these existing papers everything we agree is usable with the principles that we define (perhaps even some of the principles themselves).

In order to track and document the current state of the agreed-upon design throughout the different stages of this plan, we should use and update a leading SG23 owned profiles working paper and keep it up to date. It is a good idea to have a secondary paper containing the rationales used for decisions taken to prevent relitigation without new information.

This is an ambitious plan and will require commitment from the people working on it for it to be realistic.

4 References

1. P3081R2 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3081r2.pdf)
2. P3589R2 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3589r2.pdf)
3. P3700R0 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3700r0.html)
4. P3984R0 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3984r0.pdf)