profiles R0. we've been doing profiles R0 for five years now. this is like groundhog day but the groundhog is a WG21 paper number.

we must accept only code that's not too complex to analyze

This is the sentence that should have been in the abstract. The entire paper's guarantee has an asterisk, and the asterisk says "unless the code is hard."

I've spent the last four years working on lifetime analysis tooling. The problem isn't the easy cases - yeah, you can catch the push_back invalidation example in the paper. That's freshman stuff. The problem is the exponential blowup when you have:

1. Conditional returns of pointers with different origins
2. Callbacks that store references into containers
3. Type-erased handles (any, function, coroutine_handle)
4. Placement new into aligned_storage or successor types

The paper acknowledges this ("fundamentally impossible to statically analyze") but then handwaves the boundary. What happens at the edge? The paper says reject the code. Rejection means refactoring. Refactoring means cost. Nobody's quantifying that cost.

Rust solved this by making the boundary explicit in the type system - lifetimes are part of the signature. Profiles tries to infer the boundary from existing C++ semantics, and the paper admits the inference has limits. The question isn't whether profiles can handle the vector example. The question is what percentage of real-world code falls into the "too complex" bucket.

I'd bet it's larger than anyone on the committee wants to hear.

just use Rust lol. this entire paper is 17 pages of coping with the fact that C++ can't do what Rust does by default.

From section 1:

we avoid having to rely on developers following guidelines and sprinkling annotations all over the code

From section 2.6:

Add a [[not_invalidating]] attribute to be used to speed up analysis

The paper argues against annotations in section 1 and introduces a new annotation in section 2.6. I realize these aren't technically the same thing - [[not_invalidating]] is "just an optimization" per the paper - but in practice, any non-trivial API surface will need this on dozens of functions to avoid false positive rejections.

The annotation burden for the standard library alone is non-trivial. vector::size(), vector::empty(), vector::capacity(), map::find(), every const accessor on every container - all need [[not_invalidating]] or the analyzer assumes the worst. And getting it wrong means either false rejections (annotation missing) or false safety (annotation wrong on a function that does invalidate).

The paper says the annotation "can be verified when the function definition is compiled" - but the implementation cost of re-analyzing every annotated function under profile rules is itself non-trivial. This is the kind of detail that separates a 17-page vision document from a specification.

great, another paper that will take 10 years to get through committee

The runtime checks concern me. The paper says "eliminating undefined behavior (supported by runtime checks where necessary)" and that's the part that makes embedded developers nervous.

We run on Cortex-M4 with 256K flash and 64K RAM. Every byte matters. Every branch matters. If profiles means my span access now has a bounds check that I can't elide, that's a non-starter for ISR code.

The paper claims no "inessential overheads" but doesn't define "inessential." In my world, a single branch in a tight loop is essential overhead. I need to know: can I opt into type-safety for my application layer and opt out for my HAL code within the same TU? The paper's TU-level granularity might be too coarse for us.

For context, here's the profiles paper trail for anyone trying to follow along:

- P1179 - Lifetime safety (the original Sutter/Stroustrup proposal, 2019)
- P3038 - Stroustrup's initial profiles framework
- P3081 - Core safety profiles for C++26
- P3274 - Framework for profile development
- P3390 - Safe C++ (Baxter's competing approach)
- P3586 - "Problems with profiles" (the rebuttal paper)
- P3984 - This paper (type-safety profile detail)

That's seven papers on the same problem space and I'm probably missing a few. SG23 has been trying to navigate between profiles-first and safe-C++-first for two years now. The Wrocław meeting reportedly had polls where profiles won priority, but "won priority" and "achieved consensus" are very different things in committee-speak.

The fact that this paper targets four groups (EWG, SG12, SG20, SG23) suggests Bjarne wants to go wide rather than deep through SG23 alone. That's either strategic or an acknowledgment that SG23 isn't converging.

I work on a major C++ compiler's frontend and my eye is twitching reading section 2.6. the invalidation analysis as described is... let's say "optimistic" about what compile-time analysis can achieve in reasonable time.

Section 2.4. Copies and moves. The entirety:

To be handled similar to constructors and destructors.

That's it. That's the section. One sentence for the feature responsible for approximately 40% of all non-trivial C++ bugs I've seen in production. Move semantics alone has generated more committee papers than some entire programming languages have features.

16.67ms per frame. That's what I have. Runtime bounds checks on every container access in our ECS iteration? No.

But - and I need to be honest here - 90% of our codebase isn't the hot path. Our UI code, our asset pipeline, our network layer, our scripting bridge - all of that could benefit from profiles. The question is granularity. Can I profile-protect my asset pipeline code while leaving my particle system alone?

The paper talks about TU-level opt-in. Most game engines don't organize TUs by "safe" and "unsafe" - they organize by system. I'd need something finer.

We measure in nanoseconds. Literally. Our hot path processes market data at 2.3 million messages/second and every conditional branch matters.

The paper says profiles insert "run-time checks to ensure that an error action is triggered rather than reaching the point of UB." In our world, we've spent years removing runtime checks. We know our data is valid because we control the entire pipeline. Adding bounds checks to our span access in the matching engine would cost us about 3ns per message. At our volume, that's 6.9 milliseconds per second of pure overhead.

I want type safety for our configuration layer, our logging, our REST API code. I do not want it anywhere near the matching engine. The paper's TU-level granularity is better than nothing, but what I really need is function-level or scope-level opt-in.

committee gonna committee. see you all in 2030 when we're debating the exact semantics of [[not_invalidating]] for the 47th time.

The fundamental question isn't "do profiles work" - it's "do profiles work well enough compared to the alternative."

Circle's Safe C++ gives you a borrow checker. Actual ownership tracking in the type system. The compiler knows who owns what and for how long. The cost: new syntax, new semantics, a learning curve.

Profiles gives you: "we'll reject code that's too complex and ban some features." The benefit: no new syntax, opt-in, links with everything. The cost: the guarantee has escape hatches.

Both are trying to answer the same question from the NSA and CISA: "prove your code is memory safe." But they answer it at different confidence levels. A profile says "we checked everything we could check." A borrow checker says "we checked everything."

The committee chose profiles. I'm not sure the committee chose correctly, but I understand the politics.

I teach intermediate C++ at a university. The paper opens with Bjarne's original motivation - combining C's hardware access with Simula's type safety. My students weren't born when Simula was relevant.

What I need from profiles is: "turn this on and 80% of the footguns disappear." What this paper gives me is: "turn this on and some footguns disappear but the boundary is complex and you need to understand [[not_invalidating]] and the invalidation analysis rules and which code patterns are 'too complex for the analyzer.'"

That's not a win for pedagogy. It's another thing to teach. I'd rather have fewer guarantees with a simpler mental model than more guarantees with escape hatches students don't understand.

ok but real talk how does this interact with build systems. is -fprofile=type_safety a compiler flag? a pragma? a module attribute? the paper doesn't say and that's kind of important for anyone who actually has to ship this.

Section 2.2 defines a resource as something that "must be acquired before use and released after its last use" - but then immediately narrows it to things with constructor/destructor pairs.

This means every C API resource (FILE*, HANDLE, socket fd, OpenGL context, Vulkan handles...) is invisible to the resource-safety profile until someone wraps it. The paper's answer is "encapsulate first." But the entire point of profiles is to help code that ISN'T already following best practices. If your code already wraps every C resource in RAII, you've already solved the problem profiles is trying to solve.

See Microsoft's GSL and the Core Guidelines - they've been trying to get people to wrap raw resources for a decade. Profiles adds enforcement but doesn't solve the adoption problem.

The invalidation example in the paper is the easy case. Here's the hard one:

auto get_ref(std::map<int,std::string>& m) {
    auto [it, inserted] = m.try_emplace(42, "hello");
    return std::string_view{it->second};
}

void use() {
    std::map<int,std::string> m;
    auto sv = get_ref(m);
    m.clear();            // invalidates sv
    std::cout << sv;      // dangling string_view
}

The string_view returned from get_ref aliases memory owned by the map. The map isn't modified through the same reference chain. How does the profile track this? The paper says "don't let a pointer to a deleted object out of the function" but get_ref returns a pointer to a VALID object - it only becomes invalid when m.clear() is called later, in a different scope.

This is the class of bug that actually kills people in production, and I don't see how the rules in section 2.6 handle it without whole-program analysis or Rust-style lifetime annotations.

nobody's gonna talk about the elephant in the room? the NSA memo, the CISA guidance, the White House push for memory-safe languages. this paper exists because governments are about to start mandating this stuff and C++ doesn't have an answer yet.

I actually read the whole paper. Including section 5, the plan for progress.

The plan basically says: implement the type-safety and resource-safety profiles, get experience, iterate. It references prototypes ([HS21, CG, GDR25]) and suggests that the work is "sufficiently detailed to be translated in standardese with relatively few technical changes."

The word "relatively" is doing a lot of heavy lifting there. The gap between "here's a set of rules described in English prose" and "here's normative wording that three independent compilers can implement compatibly" is where profiles papers go to age. P1179 (lifetime safety) was 2019. We're in 2026. "Relatively few technical changes" in committee time could mean 2030.

The real question in section 5 isn't the plan - it's whether the committee has the patience for another iteration cycle on the same idea while the industry pressure for memory safety keeps growing.

Bjarne wrote this on a typewriter, I'm convinced. the formatting screams "I use Word and I'm not sorry about it."

can we please get networking in the standard before I retire. asking for a friend who started the petition in 2014.

the paper references itself as [BS25b, BS22b, BS23]. Bjarne really said "for further reading, see: me." king behavior honestly.

I just want to write a web server in C++ without worrying about use-after-free. is that too much to ask.

compiles first try if you never use raw pointers. profiles just makes that the law. I'm here for it actually.

One thing that hasn't gotten enough attention: the paper explicitly says "a profile cannot change the semantics of a program beyond defining the meaning of some forms of undefined behavior" and then says profiles insert "run-time checks."

Runtime checks are overhead. The paper says profiles don't impose "inessential overheads." But who decides what's essential? A bounds check on vector::operator[] is essential for safety and inessential for performance. You can't have both.

The zero-overhead principle was the constraint that prevented Stroustrup from enforcing safety in the first place - he says so explicitly in the introduction. Profiles tries to thread the needle, but the needle hasn't gotten any wider in 40 years.

Edit: to be clear, I'm not saying profiles is wrong. I'm saying the paper should acknowledge the tension directly instead of papering over it with "inessential."

imagine explaining profiles to a recruiter. "what are your safety profile preferences?" "I prefer type_safety with resource_safety but I opt out in my ISR handlers." recruiter: closes laptop

this paper has been my entire personality for the last month and I'm not ok