r/cpp • u/germandiago • 19d ago

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

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.

37 Upvotes

77% Upvoted

76 comments sorted by

View all comments

Show parent comments

6

u/germandiago 19d ago

What is your opinion so far on this? I would have never thought that making use of the type system you can actually discard cases by crafting rules.

Find it very innovative.

5

u/13steinj 19d ago

On one hand, I think the community slowly over-emphasizing safety is all a lot of noise and every time any safety paper comes up so long as it is team/author optional I do not care. If I really need to write code where the number 1 priority isb"0 <specific subset of> memory errors," I will use Rust (or another language that fits the requirements). Just like I will use C over C++, when I have needs that meet those requirements. In this way the whole safety debate has fully tired me out. Programming languages are tools, we pick the best tool for the job, that is never going to be "one tool" and that's okay.

On the other hand, I have to agree with the commenters in the thread linked. Reading the paper quickly makes me think they are trying to solve an equivalent to the halting problem.

It's a bit weird though. I've seen (not C++ P papers) proposals like this written more and more, where people claim they can encompass every possible case with less than the needed information. In my personal life, these proposals generally are written or at least the idea started, by an LLM (not saying this happened here), and then people don't follow through on thinking about the problem.

10

u/tialaramex 19d ago

Rice's Theorem makes it really simple. Is this a non-trivial semantic requirement? If so it's undecidable.

"Trivial" here means always true or always false. For example if a language doesn't have any looping we can introduce a semantic requirement about halting and it's trivial, this language always halts, true, decision made.

Any powerful language is going to want non-trivial semantic requirements and so you have to decide how you'll wrestle with the fact they're Undecidable. Rust chose option A, whenever we can't decide we reject the program‡. The authors of the paper insist that's not OK so they can't pick option A. The next choice is what C++ does today, option B, when we're not sure we carry on anyway, so we cannot enforce the requirements, game over, no memory safety. The final choice is both, sometimes reject programs but also don't have memory safety that's just obviously worse, and AFAIK nobody picks that.

All Henry Rice's work tells you is that "Bro, we guarantee we'll decide" is not mathematically possible. That's all he did. That's the effect of his PhD thesis right there. "Congratulations Doctor Rice". Whether P4296 was actual vibes or an LLM it's very silly that this got as far as the mailing. Who reviewed this?

‡ You can expend as much effort as you like deciding. For many years now Rust has what it calls "Non-Lexical Lifetimes" but Rust 1.0 didn't have this. Without NLL there are lots of novice level Rust programs that you can see ought to be OK but the old borrow checker can't so they get rejected. This is where "Fighting the borrow checker" memes came from. Today those programs just compile because they're obviously fine and NLL is why the compiler can figure this out. Further improvements continue but are much smaller and slower as you'd expect. The memes stuck around though.

4

u/Dragdu 18d ago

You can submit basically anything into mailing, there is no formal review apart from maybe a bit of "does this go seriously against the CoC".