What’s the problem? It makes perfect sense to me that a const object cannot be moved from, since it violates the constness. Since constness goes hand in hand with thread safety you really don’t want that violation.

▲

spot5010 9 hours ago | parent | next [-]

Maybe a compiler error that a const object cannot be “moved”?

That would force the programmer to remove the std::move, making it clear that its a copy.

▲

fluoridation 7 hours ago | parent | next [-]

There are cases where you would not want to reject such code, though. For example, if std::move() is called inside a template function where the type in some instantiations resolves to const T, and the intent is indeed for the value to be copied. If move may in some cases cause a compiler error, then you would need to write specializations that don't call it.

	▲	spot5010 7 hours ago \| parent [-]
		I didn’t think of that, but you are right. At some point I thought I understood templates r-value references work but now I’ve forgotten.

▲

ziml77 8 hours ago | parent | prev | next [-]

It's weird that they made a mistake of allowing this after having so many years to learn from their mistake about copies already being non-obvious (by that I mean that references and copies look identical at the call sites)

▲

lang4d 7 hours ago | parent | prev [-]

clang-tidy has a check for this case

▲

j1elo 8 hours ago | parent | prev [-]

To be honest I agree that it makes sense, at least if we put our hats of puritanism on the conceptual and semantical way of seeing it.

But having std::move silently fall back to a copy constructor is not a good solution.