You mean, that if there isn't some kind of (automated) enforcement, programmers will continue to "taint" code with unsafe elements? Yes, but just like one might

You mean, that if there isn't some kind of (automated) enforcement, programmers will continue to "taint" code with unsafe elements? Yes, but just like one might anticipate the development of a good IDE/tool/libray/SDK ecosystem for Rust, you could imagine the development of a memory safety enforcement/verification tool for either SaferCPlusPlus or C++ in general. The C++ "Core Guidelines Lifetime Checker"[1] is intended to be such a tool for C++ in general. And such a tool for SaferCPlusPlus would be simple enough that, if it didn't want to wait for one, an enterprise could implement one itself. I mean, all it would have to do is identify any instances of potentially unsafe elements in the code. Right? Or are you suggesting that it would be "politically" unrealistic to impose a prohibition on unsafe C++ code in the enterprise context? So it would be more realistic to adopt a new language, like Rust, that doesn't have the baggage that C++ does? [1] https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/ https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-gu...