This approach does not "demonstrate a straightforward path to achieving the same level of memory safety in C++ as Rust". One reason is that the approach is tigh

This approach does not "demonstrate a straightforward path to achieving the same level of memory safety in C++ as Rust". One reason is that the approach is tightly constrained to analyze Owners which own a single type of objects, all of which are treated uniformly. So, for example, a class which owns two different kinds of data simply can't be analyzed usefully by this approach. More details here: https://robert.ocallahan.org/2018/09/more-realistic-goals-for-c-lifetimes-10.html https://robert.ocallahan.org/2018/09/more-realistic-goals-fo... The new lifetimes proposal has explicitly revised its goal from "safe C++ subset" to "catch some common errors". That's good, because it's far more realistic and still very useful, but it's going to be problematic if people think that these guidelines imply the existence of a statically checkable, useful safe C++ subset.