Comment by secondcoming

Comment by secondcoming 14 hours ago

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 14 hours ago

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.

Reply View 4 replies

fluoridation 12 hours ago

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.

Reply View | 1 reply
- spot5010 12 hours ago
  
  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.
  
  Reply View | 0 replies
ziml77 13 hours ago

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)

Reply View | 0 replies
lang4d 12 hours ago

clang-tidy has a check for this case

Reply View | 0 replies

j1elo 14 hours ago

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 View 0 replies