Memory safety without lifetime parameters

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3444r0.html

by todsacerdoti • 2 years ago

100 42 2 years ago

This proposal implements two sets of constraint rules. Free functions constrain return references by the shortest of the argument lifetimes. Non-static member functions constrain return references by the implicit object lifetime.

It seems like this proposal just chooses a general set of constraints and forces it everywhere? Under these rules you couldn't e.g., have a regex object with a match method that takes a string and returns a reference to that same string. Seems too limiting to be practical.

leni536• 2 years ago

No, it explores this particular design, but concludes that lifetime annotations are needed.

aw16211072• 2 years ago

The draft for this paper was submitted a few days ago at https://news.ycombinator.com/item?id=41850258 (3 points, no comments). Not sure if there are any differences between the two versions.

ndesaulniers• 2 years ago

Overall interesting read. I'm rooting for Sean. If he has faith that C++ is not too far gone to be saved...perhaps I can, too.

Explain the infeasibility of making legacy lvalue- and rvalue-references memory safe.
Relocation must replace move semantics

He advocates for adding lots of things to the language, but that point is a massive change to the language IMO. I definitely think move semantics are awful; as is the hierarchy of rvalues (xvalues and glvalues) is nuts, but at this point can they be removed from the language? Or do I misinterpret the point? Perhaps this is different between unsafe blocks (vs default safe blocks)?

pjmlp5• 2 years ago

If you check the flames on Reddit, not sure if he will keep at it, the WG21 feedback has been pretty disapointing, hence this paper, as kind of response to those replies.

Most folks at WG21 think profiles will magically solve the problem, even though many of the ideas are only available on paper, not a random C++ compiler.

The biggest issue is that while a language like Ada also has profiles, the safety culture is much different, and they are part of the ecosystem since Ada83, not something that was added later.

blub2• 2 years ago

Author’s paper also doesn’t solve the problem, because I wager most C++ programmers wouldn’t touch this rustified C++, which manages to look even worse than the already not light on the eyes original.

jeffreygoesto• 2 years ago

It is a gargantuan endeavour tbh. I am writing safety C++ code for a living and still am undecided if it is a good idea to continue to do so. Safety benefits a lot from understandability and that is undoubtedly better with simple code and a simple(r) language.

Trying to keep the legacy code alive through compatibility introduces more than two languages in one, as all the combinations must be understood as well. Wrapping legacy code into bigger "unsafe" blocks and guarding the perimeter of that block is not a bad idea, it creates less mix to reason about.

Would allowing only safe references in safety code really hinder adoption?

AlotOfReading• 2 years ago

The folks talking about profiles and the folks talking about rust-like semantics are speaking past each other. They're not solutions to the same problem. Profiles is essentially "let's formalize the 80% cases of easy static analysis rules and deal with the hard stuff later". It doesn't get you memory safety in the sense of rust where it's safe if it compiles (modulo unsafe).

Animats3• 2 years ago

Not sure what to make of this. Is this a feature, or a whole design?

The idea here is simply that if the whole call tree can be examined, rather than only looking at one module at a time, less annotation is needed. That's reasonable enough, although it may result in long compile times.

What I don't see here is:

- How are circular references handled?

- C++ objects implicitly have links from parent to child and child to parent. So there's built-in circularity. How does that work?

- What about interior mutability?

Examining the whole call tree is useful. It allows catching mutex deadlocks where a thread locks against itself and stalls. It may be possible to replace something like Rust's RefCell with something, perhaps "SafeCell", that supports the same .borrow() and .borrow_mut operations, checking them at compile time for overlapping borrow scopes.

j16sdiz• 2 years ago

- C++ objects implicitly have links from parent to child and child to parent. So there's built-in circularity. How does that work?

Can you elaborate? In my understand, the parent/child relation are on the class not the object itself.

Animats3• 2 years ago

A child class can reference fields in the parent, and the parent can call virtual functions in the child.

aw16211072• 2 years ago

Not sure what to make of this. Is this a feature, or a whole design?

My (high-level) understanding is that this is a response to some feedback [1, 2] to the author's previous paper [0] which (very generally speaking) adds some Rust-like systems/semantics to C++ to achieve memory safety. Some commenters voiced disapproval of the need for lifetime annotations and expressed a desire to find a solution that doesn't require them. I think this paper is an exploration of that idea to see what can be achieved without lifetime annotations.

[0] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34...

[1] https://old.reddit.com/r/cpp/comments/1ffgz49/safe_c_languag...

[2] https://old.reddit.com/r/cpp/comments/1fiuhb7/the_empire_of_...

einpoklum3• 2 years ago

Whole new design which Sean Baxter suggests the committee foist upon C++. Being a continuation of "safe C++", it seems to be part of coping with the challenge of the popularity of Rust - and perhaps even more with how some lobbyists have gotten the US government to adopt some decisions against using "memory-unsafe languages".

Just remember that WG21 papers are their authors' position/claims, not the committee's or the community's, unless accepted. I think, or rather hope, this is not accepted.

p1necone• 2 years ago

Seeing this on HN feels a bit like those apocryphal stories of the professor who hands out the "read all the questions before you start" quiz, and the last question just tells the students to ignore everything else, wait 30 minutes and leave for full marks.

devnull32• 2 years ago

This appears to be a out of season April Fool's joke.

Am I the only one who thinks the this sacrifices the readability?

rfoo2• 2 years ago

It may be done on purpose? To me this looks like a satirical piece in response to some "nooooo how dare you introduce lifetime annotations to C++"-style comments on the same author (Sean Baxter)'s C++ lifetime annotation proposal.

devnull32• 2 years ago

On the other hand its published on open-std.org which adds to its credibility

flohofwoe2• 2 years ago

C++ isn't exactly famous for being readable to begin with.

If the name Sean Baxter doesn't ring a bell, he's creating the Circle compiler which one step after another fixes the problems of C++ (while not trailing off into a completely new language):

https://www.circle-lang.org/quickref.html

einpoklum3• 2 years ago

which one step after another fixes the problems of C++

Somehow, multiple groups of people have recently decided they want to "fix the problem": Carbon, Circle, CppFront2. But apparently, it's different fixes, and the formulation of the "the problem" is different.

I am wary of rushing to do this, considering the fate of the D, a previous attempt to "fix the problem" with C++.

account422• 2 years ago

The examples in the proposal already look like a completely new language. And yes, one that is significantly less readable than C++.

mmaniac• 2 years ago

I'm not a fan of Rust, but my God, just use Rust instead of this. This is unreadable.

burjui• 2 years ago

Even plain C++ is very hard to read, it's one of the reasons I ditched it. Cannot even imagine writing code in this version. C++ is overcomplicated already, imho it's best to leave it to die naturally instead of prolonging the suffering of millions that use it.

Memory safety without lifetime parameters

Related Stories