3 ms·
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 wi
by secondcoming 9mo 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 9mo agoMaybe 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.
- ziml77 9mo agoIt'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)
- fluoridation 9mo agoThere 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 9mo agoI 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.
- lang4d 9mo agoclang-tidy has a check for this case
- j1elo 9mo agoTo 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.