The main strength of a memory-safe language is that the safety mechanisms are opt-out, not opt-in: you can confine the unsafe behavior to a small, manageable portion of the codebase. And trying to "fix" C to become a memory-safe language would probably just result in something like a Rust dialect that merely bears more superficial resemblance to C. In any case, thorough re-writing of existing codebases would be required. You might as well re-write in a language that currently exists, rather than add creating a new language to the top of the to-do list.
I would call C++ a memory safe language that has more than a superficial resemblance to C. Rust makes is more obvious when/where you are intentionally opting out, but most C++ memory bugs are where someone opted out of the modern C++ way to use the C way. (including new/delete as the C way).
This is a common viewpoint but also wrong. There's plenty of ways to invoke memory unsafety in 'modern' C++: iterator invalidation is probably the biggest source.
While you are technically correct, those who study C++ security note that those are a tiny minority of all security errors. Still an issue, but not nearly as common an issue as the ones that come from the C roots of C++.
Also can you link to an example of this purported memory safe C++ compiler? Please note for an apples to apples comparison it must reject all memory unsafe non-modern C++ constructs.
If C++ compilers had a default mode of rejecting code that was unsafe (any code using raw pointers or unchecked array access, I guess?), then sure- you could call it that. But as it is, no way.
