A little different, but only in the sense of being, for the moment, less ambitious (than Rust) about the completeness of the checker's implementation. But I think it substantially demonstrates a straightforward path to achieving the same level of memory safety in C++ as Rust.
> For example: > > We do not attempt to address all aliasing cases
It seems to me that a main principle behind the design of the Rust language was to eliminate the aliasing issue, by imposing the "mutable references are exclusive" restriction, as a prerequisite to addressing the memory safety issue. And there was an implication (and sometimes more than that) that as long as C++ can't address the aliasing issue it can't address the memory safety issue (like Rust can).
I think the key thing that the lifetime checker demonstrates is that this premise is not (quite) right. You don't need to completely eliminate the aliasing issue to achieve (efficient) memory safety, you just need to address it "enough". And that can be done for C++.
Now, whether the complete elimination of the aliasing issue is, apart from the memory safety implications, a virtue that's worth the (flexibility) cost of the "mutable references are exclusive" restriction, is as far as I'm aware, still a matter of opinion. (Given the existence of the RefCell wrapper in Rust, and the ease (if not elegance) of implementing an "anti-RefCell" wrapper in C++, I'm guessing it's mostly a wash.)
> > or make concurrency safety guarantees. Programmers are still responsible for eliminating race conditions.
Data races are a separate issue, but relative to the (single-threaded) memory safety issue, I think there'd be less controversy that it can be addressed in C++ in vaguely similar fashion to Rust. [1]
But both in the case of Rust and the C++ lifetime checker, I don't think that the cost of the imposed (compile-time) restrictions in terms of code/algorithmic flexibility is being adequately acknowledged. For example, say you have a list (or whatever container) of references to (pre-)existing objects. In both cases, the restrictions require that all the objects must (be known to) outlive the list container even if there is a reference to them in the list for only a short time [2]. Imo this is an impractical restriction. In C++, you could use run-time checked pointers[3][4] to alleviate the restriction without sacrificing memory safety [5]. It's not immediately obvious to me that Rust couldn't have such a run-time checked reference as well. But others would be more qualified to make that assessment.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#multithread...
[2] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...
[3] https://github.com/duneroadrunner/SaferCPlusPlus#registered-...
[4] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...
[5] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...