C++ uses deferred destruction as a standard tool to solve a variety of problems.
std::move as applied to standard library types will leave the object in a "valid but unspecified state".[1] If you're leaving the object in an invalid state (one where the invariants are broken), you're not writing idiomatic C++.
For objects that don't have that property, you're just exchanging one kind of badness in the design for a different but ultimately equivalent badness.
The C++ compiler largely assumes that such static proof is possible by default and has no way of knowing if it is not. To address this, the C++ language has added features for annotating objects to indicate that static proofs of state are not possible at compile-time (e.g. std::launder).
Database kernels are the most extreme example of this because most objects in the address space don’t own their memory address and the mechanism that temporarily puts an object at a particular memory address is not visible at compile-time. Consequently, object location and state has to be resolved dynamically at runtime.
Rust not only has the 'as' operator for this exact purpose, but it also has the suite of traits From, Into, TryFrom and TryInto for the infallible and fallible conversions respectively.
The standard doesn't allow to disable language features.
Anyone that goes into the dark side of disabling language features is writing unidiomatic C++ with compiler specific extensions.
The same folks won't have a second thought distributing statically linked binaries that triple the size, while using languages that don't do exceptions, but then it isn't bloat, talk about being coherent.
Which anyone that bothers to make such claims, should be aware what it actually says regarding exceptions.
"On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions."
They don't use exceptions, because already started on the wrong foot, and like legacy code of Titanic size there is no turning around now.
What does the Bible of idiomatic C++ says, aka C++ Core Guidelines?
It has several advices on E section, regarding exception coding best practices.
