A política da biblioteca padrão sobre atribuição de movimentação é quea implementação pode assumir que a auto-atribuição nunca acontecerá; isso me parece uma péssima idéia, já que:

o contrato de atribuição "regular" ("cópia") em C ++ sempre foi considerado seguro contra auto-atribuição; agora temos mais um caso incoerente de C ++ para lembrar e explicar - e um sutilmente perigoso também; Acho que todos concordamos que o que é necessário em C ++ énão armadilhas mais ocultas;complica algoritmos - qualquer coisa noremove_if a família precisa cuidar desse caso de canto;seria muito fácil atender a esse requisito - onde você implementa o movimento com troca, ele é gratuito e, mesmo em outros casos (onde você pode obter algum aumento de desempenho com lógica ad-hoc), é apenas um, (quase) nunca usado ramo, que é praticamente gratuito em qualquer CPU¹; Além disso, nos casos mais interessantes (movimentos que envolvem parâmetros ou locais), a ramificação seria removida completamente pelo otimizador ao incorporar (o que deve acontecer quase sempre para operadores de atribuição de movimentos "simples").

Então, por que essa decisão?

¹ Especialmente no código da biblioteca, onde os implementadores podem explorar livremente dicas específicas do compilador sobre "resultado esperado do ramo" (pense__builtin_expect em gcc /__assume em VC ++).