Comment by secondcoming

Comment by secondcoming a day 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 a day 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 21 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 20 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 a day 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 21 hours ago

clang-tidy has a check for this case

Reply View | 0 replies

j1elo a day 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