Yes it does. That some compilers provide a way to disable mandatory language features is no argument.
> even Rust can catch panics from failure-oblivious code.
Not while maintaining that code's invariants it can't.
It's actually very relevant that huge amounts of C++ deployed in the world use -fno-exceptions, and many shops (for example, Google!) have a policy of "we do not use exceptions". I don't care about how well languages handle OOM in theory; what matters is how well they handle it in practice.
Google's C++ coding standards have done tremendous harm to the C++ community by perpetuating obsolete programming practices like two-phase initialization and lossy error reporting. Google's C++ standards also teach people that it's okay to use the STL and not worry about allocation failure, which hurts program robustness generally.
I'm not the only one who thinks so: see https://www.linkedin.com/pulse/20140503193653-3046051-why-go...
My C++ code is exceptional, modern, and robust, and anyone using -fno-exceptions can go fly a kite.
But RecoverySafe is just preventing things like "your binary heap was only partially heapified" and not "your heap is now full of uninitialized memory". You can get poisoned values out of mutexes just fine, so everything needs to put itself in a memory-safe state if a panic occurs.
One can bypass RecoverySafe in safe code with the AssertRecoverySafe wrapper.
It does however turn out that safe code in Rust is generally quite exception-safe by default. This is because safe code can't do anything too dangerous, panics are generally only caught at thread or application boundaries (so data that witnesses a panic is usually well-isolated) and there's way less places that can unwind compared to "override everything" C++. But exception safety is indeed something unsafe code needs to fight for (see the aforementioned binary heap in std).
