I thought "move doesn't move" was a fairly common C++ mantra at this point.

> I thought "move doesn't move" was a fairly common C++ mantra at this point.

It is. The fact that std::move is just a cast and that move constructors are expected to transfer resources are basic intro to C++ topics, covered in intro to constructors.

▲

LexiMax 2 hours ago | parent [-]

It's far too late to put the genie back in the bottle, but I am morbidly curious as to why the standards committee didn't choose an approach that made moves destructive.

	▲	jandrewrogers an hour ago \| parent [-]
		It solves some rare edge cases where the destruction of the moved-from object must be deferred -- the memory is still live even if the object is semantically dead. Non-destructive moves separate those concerns. There is a related concept of "relocatable" objects in C++ where the move is semantically destructive but the destructor is never called for the moved-from object. C++ tries to accommodate a lot of rare cases that you really only see in low-level systems code. There are many features in C++ that seem fairly useless to most people (e.g. std::launder) but are indispensable when you come across the specific problem they were intended to solve.