OK I'll have to rethink, and make sure everything other than arithmetic is supported for moved-from types.
Actually, in principle, a moved-from object should be a valid object, which just has an unspecified value.
IMHO any code that reads such unspecified values is buggy.
Right.
I wonder if the compiler could produce warnings for reading an unspecified value. It seems like a bad idea 99.9% of the time. It'd be cool if Valgrind could be given a hint to mark such data as non-inited.
If I had a movable class with a double I'd set it's value signaling NAN at least for a debug build.
Currently, any attempt to "use" a moved-from value results in an assertion, the only things you can safely do are destruct, assign-to, swap, or copy such values. There is a slight inconsistency though - not all number type Backends support (or need to support) move semantics. So if you switch from a fixed precision integer which simply copies (no move), to an arbitrary precision integer (moves) then you get a change in behavior. Of course any code that relies on an object having a specific value after it's been moved was IMO buggy to begin with, it's just that you might not see the asserts until you test with a move-enabled type. This is unfortunate, but I really don't want to hobble the fixed precision integers by giving them a special singular state (more code more checking), when most of the negative review comments were of the opinion that they're too heavyweight already. John.