Hacker News Reader

Comment by secondcoming | Hacker News Reader

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.

View on HN

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.

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)

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.

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.

clang-tidy has a check for this case

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.

Reply on news.ycombinator.com