Paper metadata: P3874R1 | EWG | 2026-02-23 | wg21.link/p3874r1

Reminder: be civil. The paper authors sometimes read these threads. Comments that violate Rule 2 will be removed.

*laughs in compile times*

this is why we can't have nice things, exhibit P3874

seven authors to ask a question the internet has been screaming about for three years

There's something subtle happening in this paper that I think most people skimming the abstract will miss.

The entire argument hinges on the definition of "memory-safe language" in section 2. The paper defines it as a language with a subset that is "systematically free of undefined behavior" - not just buffer overflows and use-after-free, but ALL undefined behavior. This is a significantly broader definition than what CISA, Google, and the ACM are actually talking about when they recommend "memory-safe languages." Those recommendations are about the specific class of bugs that lead to exploitable vulnerabilities - spatial and temporal memory errors.

By choosing the broadest possible definition, the paper makes the incrementalist position (profiles + contracts + hardening) look inadequate by definition. If your standard for "memory safe" is "zero UB in the safe subset," then of course no amount of profiling or hardening gets you there. But that's a definitional choice, not an empirical finding.

The paper actually acknowledges this tension in the "weird machine" section - Ralf Jung's argument that ALL UB creates weird machines is compelling but also contested. Integer overflow UB and unsequenced modification UB are categorically different from buffer overflow UB in terms of exploitability.

This is a well-crafted direction paper, but the definition IS the argument. If you accept a narrower definition of memory safety - one focused on the specific bug classes that actually cause CVEs - the committee's current trajectory (profiles + P3100) might be adequate. The paper needs you to accept the broad definition before the conclusion follows.

Read section 2 carefully. The rest is downstream.

Edit: since people are misreading this - I'm not saying the paper is wrong to try to define the term. I'm saying the definition does more work than it appears to, and if EWG pushes back on the definition, the argument loses its foundation.

I spent two years writing Rust professionally before coming back to C++ for a game engine role. Here's what the paper gets right and wrong, from someone who's lived in both worlds:

Right: Lifetime safety IS the primary challenge. The borrow checker is the reason Rust works, and it's the reason Rust is painful. You can't have one without the other. The paper correctly identifies that bounds checking is straightforward and lifetime checking is the hard part.

Right: The subset-of-superset strategy is the only viable path. You can't break existing C++ code. Period. A new language mode or subset that opts in is the way.

Wrong (or at least incomplete): The paper underestimates how much the borrow checker constrains API design. In Rust, entire design patterns exist BECAUSE of the borrow checker - Arc<Mutex<T>> is the canonical example. You don't just bolt a borrow checker onto existing C++ patterns. You need new patterns. The paper mentions Circle and safecpp.org but doesn't engage with how much C++ API design would need to change.

Missing: No mention of the interop story. Half the value of "safe C++" is calling existing unsafe C++ from the safe subset. Rust's FFI boundary with C is a constant pain point. C++ safe-to-unsafe interop would be the defining challenge and the paper doesn't discuss it at all.

Overall: I agree with the direction but the committee needs to understand this is a 10-year, all-hands effort comparable to adding templates in the first place. The paper should say that explicitly instead of leaving it to EWG to figure out.

I work on a major C++ compiler frontend. Some perspective on the implementation side.

The paper references Rust's MIR (mid-level intermediate representation) as the mechanism that makes borrow checking work. What it doesn't mention is that Rust's MIR was designed for borrow checking from the start. C++ has no equivalent IR at the right abstraction level. Clang's AST is too high-level and LLVM IR is too low-level - both have had lifetime information stripped or never represented.

Building the equivalent of MIR for C++ means creating a new compiler pass that preserves ownership and lifetime information through templates, overload resolution, implicit conversions, and NRVO. The complexity is not comparable to what Rust had to do. Rust's type system was designed to make lifetime information recoverable. C++ was designed for maximum flexibility, which is exactly the wrong property when you want to prove lifetime safety.

This is not a "can't be done" - Circle proves it can. But Circle started with the advantage of a single-person codebase where every compiler pass could be modified simultaneously. Doing this in GCC, Clang, and MSVC independently, while maintaining backward compatibility, is a different order of magnitude.

I estimate 5-8 years of compiler work per vendor after the design is finalized. That's the real timeline the committee should be discussing.

Edit: several people pointed out that Clang's CFG analysis is closer to what I'm describing than I implied. Fair - the infrastructure isn't zero. But the gap between "can detect some lifetime issues" and "can prove lifetime safety" is still enormous.

just. use. Rust.

seriously, this paper is 15 pages of the committee slowly discovering what Mozilla figured out in 2010. you want a memory-safe systems language? it exists. it's called Rust. you don't need to rebuild C++ from the inside to get there.

Embedded perspective, since this paper won't engage with it: we can't use exceptions. We can't use RTTI. We can't use dynamic allocation in most contexts. We barely got constexpr working across our toolchains last year.

Now a paper with seven authors is proposing a language subset that requires (at minimum) new lifetime annotation syntax, a new IR in the compiler, and potentially a new standard library. The paper says this is about "new code" but our new code still runs on STM32s with 256K flash. Every feature that makes the compiler heavier makes our builds slower and our binaries bigger.

I'm not against safety. I'm against the committee designing safety features with desktop/server C++ as the only use case. If the safe subset requires Arc<Mutex<T>>-style patterns, we can't use it. If it requires runtime bounds checks, we're out. The paper should have a section on embedded constraints. It doesn't even mention the word "embedded."

Some context on the committee dynamics, since the paper doesn't discuss them and they matter more than the technical arguments:

The SG23 polls look strong - 18-2 with 5 neutral on encouraging the design direction. But SG23 is a study group that self-selects for people who care about safety. EWG is a different animal. EWG includes the people who killed P2771 ("Towards memory safety in C++") and the people who voted P3390 ("Safe C++") below profiles in the prioritization poll (19-9 with 11 for both).

The paper is carefully framed as "should we pursue this goal" rather than "here is the design." That's smart - it avoids the P3390 problem of asking the committee to evaluate a specific design before agreeing on the goal. But EWG may see it as asking for a blank check: "agree to pursue memory safety, and we'll figure out the details later." The committee has been burned by that pattern before.

Watch the poll language carefully when this comes to EWG. "Do we want C++ to be memory-safe" will poll very differently from "Do we want to add borrow checking to C++."

The section on the standard library is the weakest part of the paper and I wish the authors had spent more time on it.

in many cases it should be possible for these interfaces to soundly encapsulate existing implementations

This sentence is doing approximately all of the heavy lifting in the standard library discussion. In practice, "soundly encapsulating" the STL means:

1. Every container's iterator model needs rethinking - begin/end as separate objects is fundamentally incompatible with borrow checking
2. std::string's small buffer optimization interacts with move semantics in ways that a borrow checker can't reason about without special handling
3. The allocator model (stateful allocators, fancy pointers, propagation traits) is a lifetime nightmare

The paper handwaves this as "significant work" but doesn't give any estimate of what that means in committee-years. The range-v3 to std::ranges effort took 6+ years and that was ADDING features, not redesigning existing ones.

I support the direction in principle. But I'm tired of direction papers that treat the standard library as a "we'll figure it out later" problem.

I teach C++ to undergrads. Here's what I keep thinking about when I read papers like this:

My students already struggle with move semantics. They struggle with the difference between const& and &&. They write auto x = std::move(y); /* uses y */ and don't understand why it compiles. Adding lifetime annotations to this picture is going to be brutal.

BUT - and this is the part I don't hear from the profiles crowd - if there's a safe subset that prevents those mistakes at compile time, my students actually learn FASTER because the compiler catches their errors before runtime. The borrow checker in Rust is painful for experienced devs but genuinely helpful for learners because it surfaces misconceptions immediately.

The paper should have engaged with the pedagogical dimension. A safe subset isn't just a security feature - it's a teaching tool. But only if the error messages are good. And C++ template error messages are... a known quantity.

love how the paper opens by citing CISA and government recommendations. nothing like federal agencies telling programmers what languages to use.

the paper references Circle and safecpp.org as an existence proof but doesn't engage with the design at all. Sean Baxter literally implemented borrow checking for C++ and showed it works. the committee saw the demo. what more do they need?

The strongest section of the paper is the weird machine argument. For those who haven't read it:

a weird machine represents a computational environment which is unconstrained by language semantics and therefore vulnerable to exploitation

This is genuinely important and I don't think the r/cpp crowd appreciates it. When your program hits UB, the abstract machine's semantics no longer apply. The compiler optimized assuming no UB. The hardware executes whatever the optimizer produced. The result is a computational environment that is Turing-complete in ways neither the programmer nor the compiler intended. THAT is why UB leads to security vulnerabilities - not because of the specific kind of UB, but because UB breaks the semantic contract between programmer and machine.

The paper cites Geoff Garen's C++Now talk on WebKit memory safety: "even one weird machine bug is a sufficient gadget to reprogram an entire process." That's not hyperbole. It's a description of how real exploits work.

we can't even agree on how modules work and now we want borrow checking. the committee's eyes are bigger than its stomach.

Some historical perspective for the "this will take 10 years" crowd: yes, it will, and that's actually fine.

Concepts were first proposed for C++0x, dropped, redesigned as Concepts Lite, and finally shipped in C++20. That's roughly 15 years from proposal to standard. Modules were discussed informally since 2004, formally proposed around 2012, and shipped (barely) in C++20. Ranges went from range-v3 to C++20 in about 6 years. Coroutines: ~7 years from first proposal to C++20.

If the committee agrees on the GOAL in 2026 and the first design proposals appear by 2028, a safe subset could conceivably ship in C++35 or C++38. That's 9-12 years. By committee standards, that's actually efficient for something this fundamental.

The paper's job isn't to solve the timeline problem. It's to get the committee to agree the destination is worth walking toward. Everything else is details.

The paper makes an interesting point that I haven't seen discussed much:

C++ already has a subset which is free of UB in the form of constexpr.

This is true and genuinely important. The constexpr evaluator is a proof-of-concept for a UB-free subset of C++. If your code triggers UB during constant evaluation, it's a compile error. No weird machines, no exploitation, just a diagnostic. Consider:

constexpr int ub_demo() {
    int arr[3] = {1, 2, 3};
    return arr[5]; // compile error in constexpr
}

int runtime_demo() {
    int arr[3] = {1, 2, 3};
    return arr[5]; // UB, compiles fine, maybe exploitable
}

The paper correctly notes this is insufficient for general programming - you can't do I/O, heap allocation (in C++20), or anything with side effects. But it shows C++ already has the concept of "the compiler rejects UB in this mode." The question is whether we can extend that model to runtime code. That's... exactly what a borrow checker does.

can we please just get networking in the standard before we pursue memory safety nirvana

R0 was called "Safety Strategy Requirements for C++." R1 is "Should C++ be a memory-safe language?" At this rate R2 will be "C++ and the Meaning of Life" and R3 will just be a picture of a borrow checker.

wait, the paper says memory safety means freedom from ALL undefined behavior? So signed integer overflow is a memory safety issue? That doesn't match any definition of memory safety I've ever seen.

I know I already posted in the library sub-thread but I want to add a top-level perspective from the application developer side.

I don't care about the definition of "memory safety." I don't care about weird machines or formal PL theory. I care about whether my team can ship code that auditors will sign off on. Right now, they won't sign off on C++ for new security-sensitive components. That's not a theoretical concern - it's a business constraint that directly affects what language we choose.

If the committee says "C++ is pursuing memory safety," that signal alone changes the conversation in my organization. The paper doesn't even need to deliver the feature. It needs to deliver the commitment. The feature can take a decade. The signal needs to happen now.

The paper is right. Profiles are theater. The committee should have started this in 2020 instead of wasting three years on P3589 and the profiles framework, which cannot and will never deliver the guarantees that CISA is asking for. Everyone in SG23 knows this. The profiles prioritization poll was a political outcome, not a technical one. If you think compile-time annotations without a borrow checker can deliver lifetime safety, you don't understand the problem, full stop.

committee: "should C++ be memory safe?"
C++ developers: "should C++ compile in under 10 minutes?"
committee: "anyway about the memory safety..."

Something nobody is discussing: the paper cites the CISA roadmap and the ACM position paper, but doesn't mention that the EU's Cyber Resilience Act takes effect in 2027. That's not a recommendation - it's regulation. Software vendors will need to demonstrate due diligence on security for products sold in the EU.

The committee can debate definitions all it wants, but the regulatory environment is moving faster than the standards process. If C++ can't credibly claim to be on a path to memory safety, vendors selling products with C++ components will face increasing compliance burden. That's the real urgency behind papers like this.

I didn't read the paper but isn't this just saying "add a borrow checker to C++"? Hasn't that been tried and rejected?

my senior lead just sent this paper to our whole team with the subject line "the future of C++". I think he's been waiting for this paper for a while.

you people keep adding features nobody asked for. give me C with classes and leave me alone.

the constexpr subset being UB-free is such a good point though. imagine if we could just expand that model to runtime code. "constexpr but also at runtime" is basically what constexpr has been evolving toward anyway - constexpr new, constexpr vector, etc. maybe the safe subset is just the limit of that progression.

just read this whole thread. the encounter between former_pl_researcher and safety_skeptic_42 is better analysis than most actual papers I've read. someone send this thread to EWG.

one of the lead authors works at the Rust Foundation. I'm sure this will produce a totally unbiased assessment of whether C++ should become more like Rust.

Boost/Asio/Folly already solved most of these problems in userspace. The difference is nobody audits against "uses Boost.Asio" - they audit against "uses a memory-safe language." Standards matter for compliance even when libraries solve the engineering problem.

I just read 15 pages about whether C++ should be safe and 95 comments about whether the 15 pages are right. I need a drink.

the paper says "C++ stands at a crossroads." buddy, C++ has been standing at the crossroads since C++11. we're just really good at standing.

Edit: RIP my inbox

Edit2: to the person DMing me about Rust, please stop

Here's my prediction: EWG will poll favorably on "should C++ pursue memory safety" because nobody wants to be the person who voted against safety. Then nothing concrete will happen for 3 years because the actual design questions (borrow checker vs profiles vs something else) are where the real disagreements are, and this paper deliberately avoids them.

Agree with the direction. Pessimistic about the execution.