Not sure how this relates to your original claim, below, that I have been responding to?

> Just because you wrote at the call site that you want to pass a copy of your object doesn't mean that the callee will actually make a copy of it.

▲

fluoridation 2 hours ago | parent [-]

Meaning, just like move semantics, overload resolution can sometimes be surprising, and the compiler may not always do what you expected if you don't fully understand the types you're working with. std::move() is not special in this sense.

	▲	HarHarVeryFunny 11 minutes ago \| parent [-]
		Ah, yes, unfortunately the language says that a value parameter of type T and an rvalue parameter of type T (T&&) are both equal priority "exact matches" to a call passing an rvalue argument, but at least if that was the only difference between two functions you'd get an ambiguous overload compilation error rather than it just selecting an unexpected one. A workaround for this, if you want an rvalue parameter to match an rvalue argument during overload resolution, is to make the "value" (vs rvalue) overload a const reference argument vs a value one. So, if you have f(T&&) and f(T), and call f(std::move(t)) then you'll get an ambiguous overload compilation error, but if you instead had f(T&&) and f(const T&), then f(std::move(t)) will match the rvalue one as you may hope for.