3 ms·

> [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 th

by j1elo 9mo 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 9mo ago
There was no Rust in 2011.
- j1elo 9mo 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)
  - pjmlp 9mo 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.
    - j1elo 9mo 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?
      - mackeye 9mo ago
        a member of the c++ committee (herb sutter) is writing an compiler for an alternative c++ syntax [0], to c++, with the intent to restrict some semantics of the language for less UB, surprises, etc. i think less implementation-defined behavior is incredibly important; rvo vs std::move, dynamic function call optimization, i wish i didn't have to search asm to check for... [0]: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
      - pjmlp 9mo ago
        While I share the sentiment, compare C#14 with C# 1.0, Java 25 with Java 1.0, Python 3.14 with Python 1.0. While C++ might be worse, when you have 300+ doing proposals every three years, others aren't safer from similar churn, even if on smaller volume, and trying to keep backwards compatibility going. And we all know what happened in Python. Also Rust editions contrary to what many think, only cover a specific set of language evolution scenarios, it isn't anything goes, nor there is support for binary libraries. As for a better C++, contrary to C, where it is business as usual, there are actually people trying to sort things out on WG21, even if isn't as well as we would like to. "Making C++ Safe, Healthy, and Efficient - CppCon 2025" https://youtu.be/p52mNWsh-qs?si=AEs1dtr6_iknzATv https://youtu.be/p52mNWsh-qs?si=AEs1dtr6_iknzATv
        gpm 9mo ago
        > nor there is support for binary libraries. This is a weird call-out because it's both completely incorrect and completely irrelevant to the larger point. Rust absolutely supports binary libraries. The only way to use a rust library with the current rust compiler is to first compile it to a binary format and then link to it. More so than C++ where header files (and thus generics via templates) are textual. Cargo, the most common build system for rust, insists on compiling every library itself (with narrow exceptions - that include for instance the precompiled standard library that is used by just about everyone). That's just a design choice of cargo, not the language.
- mccr8 9mo ago
  Rust did exist in some form in 2011. Source: I ate lunch with part of the Rust team in 2011.
  - pjmlp 9mo ago
    Some form, meaning not market relevant.
- tialaramex 9mo 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.
  - pjmlp 9mo ago
    Technically correctly, when considering private circles, as per Wikipedia it was announced to the world in January 2012. Hardly something someone at WG21 would have taken into consideration when writing papers for C++0x.
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 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.
  - ziml77 9mo 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)
  - fluoridation 9mo 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.
    - spot5010 9mo 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.
  - lang4d 9mo ago
    clang-tidy has a check for this case
- j1elo 9mo 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.

by j1elo 9mo ago

pjmlp 9mo ago

There was no Rust in 2011.

j1elo 9mo 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)
- pjmlp 9mo 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.
  - j1elo 9mo 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?
    - mackeye 9mo ago
      a member of the c++ committee (herb sutter) is writing an compiler for an alternative c++ syntax [0], to c++, with the intent to restrict some semantics of the language for less UB, surprises, etc. i think less implementation-defined behavior is incredibly important; rvo vs std::move, dynamic function call optimization, i wish i didn't have to search asm to check for... [0]: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
    - pjmlp 9mo ago
      While I share the sentiment, compare C#14 with C# 1.0, Java 25 with Java 1.0, Python 3.14 with Python 1.0. While C++ might be worse, when you have 300+ doing proposals every three years, others aren't safer from similar churn, even if on smaller volume, and trying to keep backwards compatibility going. And we all know what happened in Python. Also Rust editions contrary to what many think, only cover a specific set of language evolution scenarios, it isn't anything goes, nor there is support for binary libraries. As for a better C++, contrary to C, where it is business as usual, there are actually people trying to sort things out on WG21, even if isn't as well as we would like to. "Making C++ Safe, Healthy, and Efficient - CppCon 2025" https://youtu.be/p52mNWsh-qs?si=AEs1dtr6_iknzATv https://youtu.be/p52mNWsh-qs?si=AEs1dtr6_iknzATv
      - gpm 9mo ago
        > nor there is support for binary libraries. This is a weird call-out because it's both completely incorrect and completely irrelevant to the larger point. Rust absolutely supports binary libraries. The only way to use a rust library with the current rust compiler is to first compile it to a binary format and then link to it. More so than C++ where header files (and thus generics via templates) are textual. Cargo, the most common build system for rust, insists on compiling every library itself (with narrow exceptions - that include for instance the precompiled standard library that is used by just about everyone). That's just a design choice of cargo, not the language.
mccr8 9mo ago
Rust did exist in some form in 2011. Source: I ate lunch with part of the Rust team in 2011.
- pjmlp 9mo ago
  Some form, meaning not market relevant.
tialaramex 9mo 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.
- pjmlp 9mo ago
  Technically correctly, when considering private circles, as per Wikipedia it was announced to the world in January 2012. Hardly something someone at WG21 would have taken into consideration when writing papers for C++0x.

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 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.
- ziml77 9mo 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)
- fluoridation 9mo 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.
  - spot5010 9mo 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.
- lang4d 9mo ago
  clang-tidy has a check for this case
j1elo 9mo 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.