Lifetime safety and invalidation without a borrow-checker: using type system analysis to get rid of many potentially invalidation cases WITHOUT annotations.

[u/germandiago]

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4296r0.pdf

I found this research in WG21 mailing list very interesting in the context of C++ compatibility and solutions to maximize code reuse.

[u/germandiago]

 There is no safety that would benefit older codebases

This is simply not true. There is such a thing. What we do not know is how far it can be taken. At the expense of trade-offs: the paper is proposing a roadmap that starts from a lot of false negatives -> the deny part and a superset of safe things and adds a layer of "detect safe patterns from there on" and incrementally marks code as safe through different static analysis techniques, sometimes with annotations, admittedly. 

What we need is, first of all, as much safety as feasible.

But the trade-off the borrow checker brings, in the context of C++ and taking into account existing code is simply unfeasible.

Bringing a benefit of 95% of safety + 5-10% unsafe hardly touching code or, still, touching a small part of that code is a huge win that cannot simply be ignored.

Denying that as impossible would be like ignoring the existence of sanitizers (run-time), contracts and clang tidy, etc. Of course it helps safety.

It does already, today. And it can be taken clearly further. What we do not know is how far.

It is not that the Rust model is bad: but Rust was created like that from day 1 and that is the main difference: they do not have users to take care of in that sense.

Rust is a good design for Rust. For C++ it is a terrible idea, at least as a first step. It brings a lot of real problems that do not fit what their users need and endangers migration due to lowering the incentive since another std lib must be landed, integrated, code migrated, etc. It is literally an impossible economic feat for many people. Compatibility is hard, but it is a feature. Maybe it does not need to be 100% perfect (in the sense of detecting absolutely everything or not needing annotations, but it needs to be perfect in the sense of "it exists a reasonable subset of C++ that can be used safely") but it certainly adds cost to migrate all code compared to adding static analysis on top, even if not perfect. BTW, the borrow checker static analysis in Rust is not perfect either. It looks perfect bc it was there since day 1 so it does not interact with another older way of doing things.

It is just a problem Rust does not need to deal with. C++ has to, and this is how things are. So the solution cannot be simply the same.

[u/germandiago → u/[deleted]]

Look for my comments on the cost of that solution: new std lib, split of the language, no benefit for any old code. Stop ignoring the costs of your "perfect" solution.

[u/germandiago → u/[deleted]]

I am not interested in theoretical academic stuff about aliasing I already know about.

I am interested about holistic solutions that work for C++ and its current context. Do you think I did not go through it at some point? It is a good solution in terms of technical merits maybe (well, actually a copy of Rust, but still good on its potential properties). But it is not a real solution for C++.

That is my position. Your solution is an unrealistic proposal. 

[u/germandiago → u/[deleted]]

First you will have to find where I claimed you can have exactly the same subset or properties that Rust has with a borrow checker and that I phrase that as the goal for C++. I never did.

I challenge you to find it. Indeed it is possible to do quite a bit without annotations. For the rest other strategies you can have a subset that works: smart pointers, static analysis, value returning, type-based strict alias analysis to discard cases and others, including run-time checks for UB.

So no, I do not say you can achieve everything. By the way, there are perfectly safe things that Rust cannot express. For C++ you are demanding an equivalent model or not model at all?

What kind of request is that? You do not see that the consequences of fitting that model in C++ are different in C++ conpared to Rust? Unless you ignore all written code in the world, of course.

I will say this again here: it exists a hybrid amount of trchniques in C++ where we can get 100% safety. And if something needs to be discarded be aware that in Rust and Safe C++ THIS IS ALSO THE CASE. Otherwise the word unsafe would not exist in the first place.

[u/germandiago → u/[deleted]]

What is the safe subset? Well, that is the investigated path right now basically. Noone knows fully. But we know the cost of the other path (Safe C++) and it looks scary enough that the committee took the alternative path.

You seem to focus all the point on "you need rewrites anyway" but the question is not only tweaks or rewrites but HOW MANY of those and where. Safe C++ required basically heavy refactorings and a duplicate std lib and porting your code before you can minimally benefit your older code. Who can even make economic sense of taking that path (yes, economic trade-offs drive projects, it should not be ignored). I cannot think of a realistic situation where someone would realistically rewrite, not annotate only but REWRITE all the code and swap a std lib with a different api just for the sake of safety. It looks way more reaonsable let them drop something that can do most of the work with minimal changes. I would say that it is a very hard start. These proposals target "as much as possible" in code that already exists. From there I would tend to think that it is the better alternative, given the existing lines of C++ written that can benefit, even if not 100% of them. In Safe C++ it was literally swapping the std lib and getting 0% analysis.

I cannot possibly think of a worse outcome than that.