I have seen 3 different safe c++ proposals (most are not papers yet, but they are serious efforts to show what safe c++ could look like). However there is a tradeoff here. the full bower checker in C++ approach is incompatible with all current C+++ and so adopting it is about as difficult is rewriting all your code in some other language. The other proposals are not as safe, but have different levels of you can use this with your existing code. All are not ready to get added to C++, but they all provide something better and I'm hopeful that something gets into C++ (though probably not before C++32)

>the full bower checker in C++ approach is incompatible with all current C++

Circle is an implementation of C++ that includes a borrow checker and is 100% backwards compatible with C++:

https://www.circle-lang.org/site/index.html

That is one of of the three. It isn't really backward compatible because to take adventage of it you need to write\change a lot of code.

a nice attempt but I have millions of lines of c++ that isn't going away-

"C++ isn't really backward compatible with C because to take advantage of its classes and templates you need to change so much code..."

That is not backward compatibility. In the real world people mix C and C++ all the time without a lot of complex rewriting. Most of the time they don't even write a wrapper around the C, or if they do it is a easy/thin wrapper (generally you take a function returning a pointer you have to delete and make it a smart pointer), not a deep rewrite of the C code.

All my efforts to do the above so I can mix C++ and Rust have quickly failed when I realized that my wrappers would not be thing, and thus they would cost large performance penalties.

The cxx crate offers partial interop between C++ and Rust - for example, it wraps the C++ unique_ptr (the "take a pointer you have to delete and make it a smart pointer" abstraction) so Rust can make use of it appropriately. It's nowhere near complete, but they do welcome patches and issue reports. Anyway, this isn't even all that relevant to Circle and Safe C++, that can potentially share more with C++ than Rust does, such as avoiding a separate heap abstraction so that Safe C++ might be able to free objects that were allocated in legacy C++ code, etc.

But these are not safety features

Circle is 100% backward compatible with C++. That is a technical property of the language.

You are welcome to take your millions of lines of C++ code and it will compile without change using Circle as any valid C++ code is valid Circle code, which is the technical definition of being backward compatible.

You don't need to change existing code to use Circle or the new features Circle introduces, you can just write new classes and functions with those features and your existing code will continue to compile as-is.

You don't get the advantages of circle if you are constantly dealing with code that is returning raw pointers you have to deallocate. Or APIs where you need to pass in an index which the called function then uses vectors operator []. Safe C++ (from the same guy from what I can tell) only is safe if you used std2 containers, and otherwise rewrite your C++ entirely. Sure the world would be better if we did, but that would cost billions of dollars so it isn't happening. What we need is a way to introduce some safety into code that already exists without spending billions and a lot of time to rewrite it.

By your standard C++11 isn't backward compatible with C++98.

I've seen maybe twice that many. Did one myself once. It's possible to make forward progress, but to get any real safety you have to prohibit some things.