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.
> 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.
> 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.
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.
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)?
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.
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.
> 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_...
> - 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.
A child class can reference fields in the parent, and the parent can call virtual functions in the child.
> 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.
No, it explores this particular design, but concludes that lifetime annotations are needed.
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.
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)?
This formatting and font mixing is difficult to read on mobile.
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.