It's an antipattern. Consider the following scenario: a function says "something = move(passed_by_value);". When called with an lvalue, this assumes that copy c

It's an antipattern. Consider the following scenario: a function says "something = move(passed_by_value);". When called with an lvalue, this assumes that copy construction followed by move assignment is as efficient as copy assignment would be (which is what you get when you overload for const X& and X&&, or perfectly forward). This is untrue for vector/string-like things. When you copy construct a vector/string, it must allocate space for N elements, then copy then. Move assignment just transfers ownership, that part is fast. But consider copy assignment. If the destination has sufficient capacity, NO allocation will be performed - instead, the existing elements will be destroyed and the sufficiently-large buffer reused to hold the new elements. Therefore, "want speed? pass by value" can result in worse performance. Overloading for copy/move is near-optimal and perfect forwarding is optimal - this is what the STL does (push_back is copy/move overloaded, emplace_back perfectly forwards).