Comment by j1elo

Comment by j1elo 13 hours ago

> [std::move silently copies const values, because] If something is const, you can’t move from it by definition.

Whoever wrote that definition should have a thing or two to learn from Rust. Different language I know, but it proves that it wasn't needed to cause so much confussion and collectively so much time and performance lost.

Also, who writes rules like that and ends the day satisfied with the result? It seems unlikely to feel content with leaving huge footguns and being happy to push the Publish button. I'd rather not ship the feature than doing a half-assed work at it. Comparing attitudes on language development and additions, it makes me appreciate more the way it's done for the Go lang, even though it also has its warts and all.

pjmlp 13 hours ago

There was no Rust in 2011.

Reply View 11 replies

tialaramex an hour ago

By 2011 Rust has a logo (basically its current logo), and it has a compiler written in Rust (a distant ancestor of today's main Rust compiler). It's approaching Rust 0.1 (released January 2012 apparently) which is a very different language from Rust 1.0 -- but that's a long way from "there was no Rust in 2011" to my mind.

Reply View | 0 replies
j1elo 12 hours ago

The point is not a comparison with Rust per-se, but the fact that a better implementation of the idea was mathematically and/or technically possible; and the personal opinion that such huge footguns that the language accumulates over the years are maybe signals of having needed more thought to them before they were considered ready.
e.g. if something as simple of a inconspicuous std::move in the wrong place can break the whole assumption about move semantics, then make that impossible to do, or at least do not make it the default happy path, before you consider it production ready. What the heck, at the very least ensure it will become a compiler warning?
Hence the mention to Go and how they follow exactly this path of extending discussion as long as needed, even if it takes 10 years, until a reasonable solution is found with maybe small gaps, but never huge ones such as those explained in this article (plus tens of others in any other text about the language)

Reply View | 7 replies
- pjmlp 12 hours ago
  
  It took 13 years to get C++11, actually.
  Go's discussion is interesting, given how much programming language design history, and flaws of existing languages, they ignore to this day.
  
  Reply View | 6 replies
  
  j1elo 12 hours ago
  
  A bit more if we consider the "bugfixing" release that was C++14 :)
  But yeah it makes sense, given how that was the jumpstart of the whole modernization of the language. I believe it was a big undertake that required the time it took. Still years have passed and footguns keep accumulating... it wouldn't hurt to have a mechanism to optionally drop the old cruft from the language. Otherwise everything stacks on top in the name of backwards compatibility, but at this pace, how will C++36 look like?
  
  Reply View | 5 replies
mccr8 11 hours ago

Rust did exist in some form in 2011. Source: I ate lunch with part of the Rust team in 2011.

Reply View | 1 reply
- pjmlp 11 hours ago
  
  Some form, meaning not market relevant.
  
  Reply View | 0 replies

secondcoming 13 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.

Reply View 6 replies

spot5010 13 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 11 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 10 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 12 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 11 hours ago
  
  clang-tidy has a check for this case
  
  Reply View | 0 replies
j1elo 12 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