Created attachment 29922 [details] sample program that illustrates incorrect behavior The default implementation of std::swap does self-move-assignment when calling swap(a, a), which is illegal according to 17.6.4.9.
Actually, I'll take this back. I don't believe this is a bug. 17.6.4.9 constraints arguments passed to STL functions. So if there is a library function that takes a rvalue argument (such as string::operator=(string&& other)), then the library is free to assume that the argument doesn't alias (so &other != this). So the assertion in basic_fbstring is correct. The default implementation of swap() does self-move assignment. That would be illegal if the types were MoveAssignable STL types (because then they'd call T::operator=(T&&) which would be illegal according to 17.6.4.9) BUT ALL STL TYPES HAVE SPECIALIZED IMPLEMENTATIONS OF SWAP which don't do self move assignment. So the default swap() will do self-move-assignment on user types, but there's no language in the standard that bans self-move-assignment there.
Here are two different things to consider: 1) The standard library specification of basic_string's move-assignment operator currently requires that it works for self-assignment: <quote> 21 Effects: If *this and str are not the same object, modifies *this as shown in Table 71. [...] 22 If *this and str are the same object, the member has no effect. </quote> This might or might not change, depending on the outcome of LWG issue http://cplusplus.github.io/LWG/lwg-active.html#2063 2) The generic swap template from <utility> imposes requirements on the argument types and describes what it does (which can only rely on the requirements). So if you call swap with the same argument value and if for these argument values the move-assignment is undefined behaviour, you get what you are asking for. There is no single evidence that swap would be even allowed to prevent swapping for identical arguments, because the semantics are specified clearly to exchange the two values.
Closing then.