"Should C++ be a memory-safe language?" is the kind of paper title that guarantees 200 comments where exactly 4 people have read past the abstract.

I actually read the paper. The most consequential claim is buried in the definition section and most people here will miss it.

The paper argues that "memory-safe language" doesn't mean "a language that prevents memory bugs." It means "a language that systematically prevents all undefined behavior." They quote Ralf Jung:

"it doesn't matter why your program has UB, what matters is that a program with UB defies the basic abstractions of the language itself, and this is a perfect breeding ground for vulnerabilities. Therefore, we shouldn't call a language 'memory safe' if the language does not systematically prevent Undefined Behavior."

This is a much stronger claim than what most people mean when they say "memory safe." Under this definition, signed integer overflow is a memory safety issue. Violating a [[pre:]] contract is a memory safety issue. Anything that triggers UB, regardless of whether it touches memory at all, disqualifies you.

The strategic question isn't whether this definition is correct - it's whether it's wise. By defining memory safety as "zero UB in the safe subset," you set a bar that's clear and defensible, but you also define away every incremental improvement as insufficient. Profiles? Not enough. Hardened containers? Not enough. Contracts? Not enough. Nothing short of a Rust-style safe/unsafe split qualifies.

I think the weird machine argument (any UB is exploitable, therefore all UB is equally dangerous from a security standpoint) is technically sound. But there's a gap between "technically sound" and "strategically useful for directing committee resources." You can agree that all UB is bad without agreeing that the right response is to build a parallel safe dialect of C++.

The paper knows this is the crux. The three options in "Should C++ become a memory-safe language?" are framed so that (1) is obviously insufficient and (3) is the paper's conclusion, making (2) the thing they're really arguing against. And the argument against (2) is essentially: incremental improvements can't reach the destination because the destination requires guarantees, not reductions.

That's the real debate. Not "is memory safety good" - obviously yes. The question is whether C++ should commit to guarantees when reductions might be enough to keep it viable.

the fact that a paper titled "should C++ be a memory-safe language" has a Rust Foundation employee as first author tells you everything you need to know about where C++ is right now

The paper is well-written and the definition is defensible, but there's a structural problem: it asks EWG to commit to crossing the river without showing them the bridge.

The three options are:

1. "Already safe enough" - the paper dismisses this
2. "Incrementally safe" - the paper argues this is insufficient
3. "Become memory-safe" - the paper's conclusion

But options (2) and (3) aren't mutually exclusive. You can pursue incremental improvements and explore a safe subset. The paper frames it as a choice to create urgency, but in practice the committee is already doing (2) and the question is whether to also do (3). That's a resource allocation question, not a philosophical one.

The SG23 polls tell the story. 13-5-5-2-0 for "encourage design work" - that's comfortable. 10-4-8-2-1 for "forward to EWG" - that's a lot of neutrals. The neutrals are saying "I'm not against this, but I want to see more before I commit."

Perspective from someone whose code runs on hardware with 256KB of flash and 64KB of RAM.

The paper mentions constexpr as an existing UB-free subset. That's true and it's great for what it does. But the paper also says "a subset that does not allow pointer dereference or arithmetic would not be useful." I agree - and that's exactly the tension. The features that make C++ useful for embedded are the features that introduce UB.

My concern with the subset-of-superset approach: if the safe subset can't express the low-level operations I need without escaping to unsafe, then most of my embedded code will be unsafe C++ with a safe wrapper. That's not a safe codebase - it's an unsafe codebase with a marketing label.

Rust has this same problem in embedded. Look at any no_std Rust crate and count the unsafe blocks. The ratio is much higher than application-level Rust.

The standard library section is where the paper's optimism bumps into reality. Let me quote:

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

That sentence is doing an enormous amount of work. Let's enumerate what "soundly encapsulate" actually means for some common types:

std::vector - iterators are the problem. The paper notes that "the requirements that begin and end iterators reference the same container cannot be easily enforced for syntactically separate entities." This means a safe vector needs range-based iteration at minimum. That's a different API surface.

std::string_view - the entire type is a dangling reference waiting to happen. A safe string_view needs lifetime tracking, which is the hardest unsolved problem in the paper.

std::optional<T&> - same lifetime issue.

Anything touching allocators - allocator-aware types store references to allocators that can outlive them. Sound encapsulation requires tracking allocator lifetimes.

The paper mentions std::variant as mostly declarable as safe. Sure. Now try iostream. Or regex. Or anything with locale dependencies.

I'm not saying it's impossible. Rust spent a decade building their standard library with safety in mind from day one. We'd be retrofitting safety onto 30 years of API surface. The effort is real and the paper should acknowledge its scale more honestly.

I think the paper's framing of the three options is misleading. It presents "incrementally become safe enough" and "become a memory-safe language" as competing strategies. They're not. One is a subset of the other.

P3081 (safety profiles) and P3589 (profiles framework) give us something now. They catch real bugs in real codebases today. Google's experience with hardened libc++ proved that library hardening alone eliminates a significant fraction of exploitable bugs in production.

The paper's all-or-nothing framing - either you guarantee zero UB or you're not memory-safe - ignores the practical impact of reducing vulnerability surface by 70-90%. That reduction saves real money and real lives while the committee figures out the long-term story.

I'm not against a safe subset eventually. I'm against defining "memory safe" in a way that makes everything we're doing right now sound worthless.

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

The paper references Circle as existence proof that a safe subset can be added to C++. Circle is impressive work - Sean Baxter has built a functional borrow checker for C++ that runs on Compiler Explorer today. But Circle is one person's research compiler. The gap between "one person implemented this" and "three major compilers agree on the semantics and ship a conforming implementation" is measured in years and tens of millions of dollars.

Borrow checking in Rust depends on MIR - a mid-level IR that preserves control flow information that's been optimized away by the time you hit LLVM IR. Adding an equivalent pass to GCC, Clang, and MSVC means adding a new compilation phase that doesn't exist in any of them. It's not a flag you flip. It's a new layer of the compiler.

I'm not saying don't do it. I'm saying the paper should level with people about what "some significant new feature will be required" actually means in implementation terms. It means 3-5 years of compiler work after the committee agrees on a design. And that's the optimistic timeline.

I love how the paper says "This proposal does not seek to make the perfect the enemy of the good" and then spends 5 pages arguing that every existing safety improvement is insufficient because it doesn't achieve perfection

Meanwhile CISA: "please use memory-safe languages"

C++ committee: "first we must define what you mean by that. we'll get back to you in 2029."

We measured. Bounds checking on our hot path costs 2-3ns per access. On a path processing 10M messages/sec, that adds up to a rounding error - unless you're competing against someone who doesn't pay that cost, in which case it's the difference between filling an order and missing it.

Any "safe subset" that mandates runtime checks in contexts where we need raw speed is a non-starter for us. The paper says the safe subset would restrict operations that "necessarily risk UB for the sake of performance, such as unchecked array access." If I can't do unchecked array access in the safe subset, then my entire critical path is in unsafe C++.

Which is fine - the paper says unsafe C++ continues to exist. But then the value proposition for us is "write your business logic in safe C++ and your hot path in unsafe C++." We already do that with careful engineering practices. The safe subset doesn't change our life much.

can we please just get networking in the standard before I retire. we're out here arguing about whether C++ should have a borrow checker while std::socket doesn't exist.

Perspective from someone who teaches C++ to ~200 undergrads a year.

The biggest win from a safe subset isn't the safety guarantees themselves - it's the error messages. Right now, my students write code with dangling references and the compiler says nothing. The program works on their machine, crashes on the grading server, and they spend 8 hours debugging what the compiler could have caught in 0.2 seconds.

If there's a safe subset where the compiler rejects dangling references at compile time, that's a pedagogical revolution. Not because students will write "safe C++" in industry - they might - but because compiler-enforced rules teach people what correct code looks like. Rust's borrow checker is famously frustrating for beginners, but every Rust programmer I know says it made them a better systems programmer. That's the real value.

The paper says "A memory-safe C++ is about new code." From a teaching perspective, all student code is new code.

laughs in compile times

yes let's add borrow checking to C++. I'm sure that won't add another 3x to my already 45-minute clean build

For people who don't read poll results for fun:

The revision history tells the story. Three polls in SG23 at Kona:

1. "Encourage design work in line with P3874" - 13-5-5-2-0 (consensus for)
2. "Forward to EWG" - 10-4-8-2-1 (consensus for, but eight neutrals)
3. "Forward to EWG as part of a Standing Document" - 18-4-2-0-1 (strong consensus)

Poll 1 says "most people want this explored." Poll 2 says "many people aren't ready to send it to EWG yet." Poll 3 says "almost everyone wants this in a standing document."

The gap between poll 1 and poll 2 is the interesting part. People support exploration but are cautious about escalation. That's a committee saying "we like the direction but we're nervous about the commitment." Which is exactly the tension this thread is arguing about.

Also notable: poll 3 getting 18 SF is remarkable. "Incorporate into a standing document" means "make this part of the committee's official direction." That's a strong signal, even with the caveats.

reading this paper and thread makes me think C++ is going through its midlife crisis. buying a sports car named "Safe Subset" won't make you young again. but it might keep you out of the nursing home.

The section on data race safety is surprisingly optimistic and I think rightly so. The paper notes that Rust achieves thread safety through Send and Sync traits - not language-level constructs but unsafe traits that enforce synchronization requirements through the type system. Circle adopts the same approach.

C++ already has the building blocks: std::mutex, std::atomic, std::shared_mutex. What's missing is the type-level enforcement that prevents you from accessing shared data without holding the lock. That's a concepts/traits problem, not a borrow checker problem. You could imagine:

template <typename T>
class synchronized {
    T value_;
    mutable std::mutex mtx_;
public:
    template <typename F>
    auto with_lock(F&& f) -> decltype(auto) {
        std::lock_guard lock(mtx_);
        return f(value_);
    }
};

The hard part is making the compiler enforce that you can't access the inner value without going through with_lock. That requires some notion of "this field is only accessible through this API" - which is basically what Rust's ownership model provides.

Still, thread safety might be the easier half of the memory safety problem. Lifetimes are the hard part.

memory safety? in MY undefined behavior? it's more likely than you think

The appendix has a nice example of sound encapsulation that I think a lot of people are missing. The Rust get() / get_unchecked() pattern is directly translatable to C++:

template <typename T>
auto get(size_t idx, span<T> slice)
    -> optional<T&>
{
    if (idx < slice.size()) {
        return slice[idx];  // bounds already checked
    }
    return nullopt;
}

The point is: get() is safe regardless of inputs. There is no combination of arguments that triggers UB. That's the difference between "the programmer must use this correctly" and "the API prevents misuse." We already write code like this in C++. The paper is saying: let the compiler enforce that safe code only calls safe APIs.

godbolt link if you want to play with it.

Schrödinger's C++: simultaneously dying because it's not memory safe and immortal because nothing can replace it

Has anyone thought about how a safe subset interacts with ABI? If we're adding new types, new calling conventions for safe references, new function coloring...

I've been thinking about this more and I want to revise my earlier take. I said the question is whether "guarantees vs reductions" matters. I think the real question is about composability.

With profiles and hardening, safety is a property of a build configuration. Turn on the right flags, link the right libraries, use the right analysis tools, and you get safety-ish. But that safety doesn't compose. Library A with profiles + library B with profiles doesn't give you a program with profiles-level safety, because the boundaries between them aren't checked.

With a safe subset, safety is a property of the code itself. Safe function A calling safe function B gives you a safe call chain, checked by the compiler, regardless of build flags. That composes. And composability is the thing that scales.

I still think the implementation cost is enormous. But the composability argument is what makes the paper's position stronger than "just use sanitizers."

Edit: this is what the paper means by "guarantees depend upon provable properties and automatic enforcement." Profiles are enforcement without provability. The safe subset is both.

I came from r/all. I have no idea what any of this means but it sounds like you guys are having a 300-comment argument about whether your programming language should stop crashing

The paper says constexpr is already a UB-free subset. So technically C++ is already a memory-safe language. You just have to run everything at compile time. Problem solved. Ship it.

The appendix is the most important part of the paper and almost nobody will read it. It explains something that both the "Rust is perfectly safe" and "Rust's safety is a lie" crowds get wrong.

The example with get_unchecked is key. Safe Rust code can cause UB through a chain of causality - you set an index to an invalid value in safe code, then unsafe code uses that index without checking. The UB happens in unsafe, but the "bug" is in safe code. The paper acknowledges this honestly, which is more than most safety advocates do.

The practical value isn't "safe code can't cause bugs." It's "when a bug causes UB, there's an unsafe block in the call chain you can point to." That's auditability, not perfection. And auditability is what makes Rust's approach work at scale - you know where to look.

The same would be true for a C++ safe subset. The guarantee isn't "your program is correct." It's "if your program has UB, you know which escape hatches to audit." That's a much more honest pitch and I wish the paper led with it.

bold move, publishing a paper that's basically "hey C++ committee, I know you've been doing this for 45 years but have you considered... doing it differently"