I think this is very unlikely to happen. The main value of C and C++ is in their backward compatibility. Many projects don't even use current versions the lang

I think this is very unlikely to happen. The main value of C and C++ is in their backward compatibility. Many projects don't even use current versions the languages, and stick to decades-old subsets instead. There are safety improvements that C++ could do right now, but is unwilling to do. For example, `[]` on vectors could have bounds checks. `->` on empty `std::optional` could trap instead of being UB. Rust accepts performance cost of these things, C++ doesn't want to. C and C++ move too slowly and are too fragmented and ossified to make a difference in the foreseeable future. They couldn't copy even the easy stuff like Rust's painless dependency management (C++ modules are not going well). Even if a miracle-safety-feature was invented tomorrow, it will take many many years before it goes through cycles of standardization, implementation across vendors, and new compilers being available as a baseline. Safety improvements won't be a magic compiler flag — C has already deeply invested in analyzers, sanitizers, and fuzzers to improve safety without rewrites. Rust's improvements come from a richer but stricter type system, and that requires refactorings. There are safer C dialects already that have these features, but nobody wants to add lifetime annotations and rewrite their pointer arithmetic to use slices. "Nobody's going to rewrite millions lines of code" applies the same to Safe-C. But the more Rust-like features they adopt, the easier it will be to automatically convert them to Rust.