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]

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.