See for example comments from tptacek like:
https://news.ycombinator.com/item?id=43335748
https://news.ycombinator.com/item?id=46028232
https://news.ycombinator.com/item?id=44672371
(The gist: memory safety is a term of art coined by security practitioners. Go, Python, Rust, Java, others: memory safe. C/C++: memory unsafe. Periodically, people in different slices of industry or academia come up with new definitions of memory safety that declare Rust or Go or other languages to be memory unsafe, but that is not by the broadly accepted definition across industry.)
At some point in the future, a fully backwards compatible Rust compiler will report an error when you try to compile cve-rs.
btw, it's not actually that hard to write correct code in C++, easier than in C because you have all the container types. The problem is that nothing will tell you when you write incorrect code - there's no guarantee.
I mean, sure, insofar as such a thing would also imply that a) the standard would need quite a bit of cleanup/clarification work to not contradict your definition, and b) the main optimizing C++ compilers are miscompiling code, analogous to how cve-rs is a rustc miscompilation rather than an issue with Rust itself.
(Fil-C might be an interesting exception here, though IIRC its definition of memory safety is slightly different)
There are no known instances of this bug being encountered in the wild, and if you look into it, you will see how extremely unlikely such code is.
I like Rust, but with this bug existing for so long, I personally no longer think of it as memory-safe.
I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how old/new it is. From a user's standpoint I'd imagine it's a combination of developer intent and the user's reliance on said behavior, but IIRC in this particular case there's no known non-demo code that has organically run into this particular bug so there's little weight in favor of calling the bug a feature despite the devs' stance.
Also as GP said I think one needs to be careful to distinguish between the compiler and the language. IIRC the devs have known for basically this entire time exactly in what manner the Rust compiler fail to implement the rules of Rust the language, but a general fix has been blocked on long-running projects that have only recently been approaching the finish line [1].
[0]: https://news.ycombinator.com/item?id=40431444
[1]: https://blog.rust-lang.org/2026/08/21/enabling-next-solver-o...
As an (outside go) example, Ocaml (5) promises strong memory safety, but not to be data race free. A data race is not something we can prevent, because its usually not bound by code, but by time and the race-source rarely in source-code.
This means we have data races in http, database inserts etc. The source is usually not a concurrent task in source code-land.
I do think the nitpicking about this is mostly from people that want to say “my favorite language is safer than Go” which stupid and annoying.
https://go.dev/ref/mem#restrictions:~:text=such%20races,corr...
https://www.ralfj.de/blog/2025/07/24/memory-safety.html (I don't agree with everything here, but it's a very thorough explanation)
My point is "races" happen all over. In concurrent code, databases, http and pretty much anywhere where you have some kind of timing, not scoped to a unit.
I think this should make the distinction between data races and race conditions pretty clear.
Not sure why you would be that nitpicky for something so trivial?
That throws a NullReferenceException
When we finally rid ourselves of C and C++ is so larded over with extensions and additions and features that we can finally plausibly say the C subset is just not in use anymore, we can perhaps consider as a community expanding what "memory safe" means, but in the meantime it has some very important meanings and we should not try to augment the term. Memory safety doesn't mean anything like "forcing exhaustiveness into sum type deconstructions" or "never has a race condition" (though it does mean said race condition shouldn't be something that allows you to escape out of an array or forcibly change the type on something in a way the language doesn't normally permit) or any of several other things that may be very nice to have indeed, but are not part of the definition of "memory safe".
Memory safe is a very old concept, and almost everything is memory safe now. But not quite, and as such the term still has use. And also zig for some reason gave it up so it won't be disappearing as soon as I'd like.'