Why won't move semantics work if the move operator is not marked as noexcept?

The semantics of move operations assume no exceptions, since resources (memory, descriptors) are transferred from one object to another during the move, and the original object remains in a valid but unspecified state. If a move operator throws an exception in the middle of the move process, it can lead to:

• The original object may already be modified (resources partially or fully transferred).
• The target object may not have received all resources or only received some.
• As a result, both objects may end up in an inconsistent or invalid state, leading to resource leaks or undefined behavior.

The noexcept guarantee for a move operator indicates to the compiler that this operator will not throw exceptions. This information is used by the compiler in standard library algorithms, for example, when resizing std::vector.

When std::vector needs to increase its capacity, it allocates a new memory buffer and moves or copies existing elements into the new buffer. If the move assignment operator for the element type is marked as noexcept, std::vector prefers moving. If the move succeeds for all elements, the old buffer is released. If one of the move operations throws an exception during the move, std::vector can safely roll back the operation, freeing the new incomplete buffer and leaving the old buffer (and its elements) untouched in its previous valid state. This provides the strong exception safety guarantee.

If the move operator is not marked as noexcept, the compiler cannot guarantee that the move will not throw. In this case, to ensure the strong exception safety guarantee, std::vector opts for copying instead of moving. This is because, during copying, an exception thrown while copying an element does not affect the correctness of already copied elements and leaves the original elements untouched. The rollback of the operation (deleting the incomplete new buffer) is also safe.

Thus, the absence of a noexcept guarantee for the move operator forces the standard library (and other parts of the code relying on this guarantee) to use a safer but potentially less efficient copying operation instead of moving, effectively "disabling" move semantics in scenarios where the strong exception safety guarantee is important. Move semantics only work with rvalue references and the invocation of move constructors/assignment operators, and noexcept is a key condition for safe and predictable use of this semantics in exception contexts.