It's backwards compatibility: there are hundreds of millions, or probably billions of lines of C++ code out there. I found working with big code bases really hard, because the memory ownership situation is crazy, in fact impossible to keep track of.
That's why my question was whether there's a future path for C++ Lifetime Profile to get programs to Rust like memory safety in the future, but I still don't know the answer.
The C++ language maps one-to-one to the safe subset, so auto-conversion of (reasonable) existing C++ code to the safe subset should be a straightforward (if tedious) undertaking. The issue will be the performance of the converted code, which will depend on how pointers/references are used in the original code.
Pointers that are expected to never point to (in addition to never dereference to) a destroyed object can be converted to "safe" pointers with little run-time overhead [2]. Otherwise the pointer would need to converted to one with more overhead [3]. Pointers that can be verified (by the static analyzer) to conform to "scope lifetime" rules (akin to Rust) can remain zero-overhead pointers.
New code written in the safe subset would generally have performance in the ballpark of traditional C++ [4].
[1] https://github.com/duneroadrunner/scpptool
[2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...
[3] https://github.com/duneroadrunner/SaferCPlusPlus#registered-...
[4] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG... (note that the benchmark code is quite old and will be updated soon)
Auto-conversion of code that uses pointer arithmetic is challenging, but has been demonstrated to be solvable in the general case [2].
[1] https://github.com/duneroadrunner/SaferCPlusPlus#getting-sta...
[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
I hope it gets enough backing from corporations that have big/huge C++ code bases.
So any improvement to the status quo is pretty much welcomed, and here lies the big difference between the C++ (introducing lifetime profile) and C communities (making Annex K optional), regarding taking actions to fix memory corruption.
I think Rust captures the core lifetime concepts pretty well, but the notation can be cumbersome, and I think C++'s rich type-system could make for a less-tedious solution. TFA mentions doing some implicit lifetime-analysis based on signatures (e.g. inferring ownership based on type-traits), but ultimately it is 'just' low-hanging fruit. It would be nice to capture in signatures/types that "the input must outlive the output" and have more meaningful error diagnostics and less implicit magic ("did I follow the iterator traits correctly?").