4 ms·

Is C++26 getting destructive move semantics?

28 points by signa11 11mo ago

andrewmcwatters 11mo ago
That commenter’s syntax notation looked pretty neat and intuitive.
staplung 11mo ago
Sounds like the answer is no. "For trivial relocatability, we found a showstopper bug that the group decided could not be fixed in time for C++26, so the strong consensus was to remove this feature from C++26." [https://herbsutter.com/2025/11/10/trip-report-november-2025-iso-c-standards-meeting-kona-usa/ https://herbsutter.com/2025/11/10/trip-report-november-2025-...]
- ogoffart 11mo ago
  I’m curious what that showstopper bug actually was. I was really looking forward to this feature, as it would've helped improve Rust <-> C++ interoperability.
  - pwdisswordfishy 11mo ago
    https://quuxplusone.github.io/blog/2025/11/18/kona-trip-report/#p2786-versus-p1144 https://quuxplusone.github.io/blog/2025/11/18/kona-trip-repo... goes into more detail.
    - anordal 11mo ago
      Thanks for the link!
CosmicZombie 11mo ago
After learning Rust, C++ just seems unnecessarily complicated. I'm not even going to try to understand this. Using C++ these days feels like continuing to use the earth-centric solar system model to explain the motion of planets vs a much simple sun-centric model: Unnecessarily over-complicated.
- deleted 11mo ago
  [deleted]
- drnick1 11mo ago
  Rust just doesn't work for a lot of applications. Things like GUI toolkits, Web browsers, game engines are a pain to write without true OOP. Yes, it's "overly complicated" at this point after about 40 years of development, buts it's still top 3 of the TIOBE index after all these years for a reason.
  - ogoffart 11mo ago
    Of course Rust can handle those use cases fine (GUIs, web browsers, and game engines). C++ is still high on the TIOBE index mainly because it is indeed old and used in a lot of legacy systems. For new projects, though, there's less reason to choose C++.
    - drnick1 11mo ago
      It's still high because it solves real world problems, so it's still the gold standard for anything ranging from systems programming to scientific computing.
    - Calavar 11mo ago
      Web browsers, yes. With GUIs and games, it's a less clear. Of course you can write GUIs and games in any Turing complete language but there's still a lot of work to be done in finding the right ergonomics in Rust [1, 2]. [1] https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-ha... [2] https://loglog.games/blog/leaving-rust-gamedev/ https://loglog.games/blog/leaving-rust-gamedev/
      - koakuma-chan 11mo ago
        You are saying "With GUIs and games" as if there is any GUI framework or game engine that doesn't suck.
    - deleted 11mo ago
amluto 11mo ago
IMO destructive move is rather tangled up with another language feature: the ability to usefully have a variable of type T where all values must be actual values that meet the constraints of a T. Suppose T is a file handle or an owning pointer (like unique_ptr), and you want to say: T my_thing = [whatever] and you want a guarantee that T has no null value and therefore my_thing is valid so long as it’s in scope. In C++, if you are allowed to say: consume(std::move(my_thing)); then my_thing is in scope but invalid. But at least C++ could plausibly introduce a new style of object that is neither copyable nor non-destructively-movable but is destructively movable. Interestingly, Go is kind of all in on the opposite approach. Every instance of: my_thing, err := [whatever] creates an in-scope variable that might be invalid, and I can’t really imagine Go moving in a direction where either this pattern is considered deprecated or where it might be statically invalid to use my_thing. I actually can imagine Python moving in a direction where, if you don’t at least try to prove to a type checker that you checked err first, you are not allowed to access my_thing. After all, you can already do: my_thing: T | None = [whatever] and it’s not too much of a stretch to imagine similar technology that can infer that, if err is None, then T is not None. Combining this in a rigorous way with Python’s idea that everything is mutable if you try hard enough might be challenging, but I think that rigor is treated as optional in Python’s type checking.

28 points by signa11 11mo ago

That commenter’s syntax notation looked pretty neat and intuitive.

Sounds like the answer is no. "For trivial relocatability, we found a showstopper bug that the group decided could not be fixed in time for C++26, so the strong consensus was to remove this feature from C++26." [https://herbsutter.com/2025/11/10/trip-report-november-2025-iso-c-standards-meeting-kona-usa/ https://herbsutter.com/2025/11/10/trip-report-november-2025-...]

ogoffart 11mo ago
I’m curious what that showstopper bug actually was. I was really looking forward to this feature, as it would've helped improve Rust <-> C++ interoperability.
- pwdisswordfishy 11mo ago
  https://quuxplusone.github.io/blog/2025/11/18/kona-trip-report/#p2786-versus-p1144 https://quuxplusone.github.io/blog/2025/11/18/kona-trip-repo... goes into more detail.
  - anordal 11mo ago
    Thanks for the link!

CosmicZombie 11mo ago

After learning Rust, C++ just seems unnecessarily complicated. I'm not even going to try to understand this. Using C++ these days feels like continuing to use the earth-centric solar system model to explain the motion of planets vs a much simple sun-centric model: Unnecessarily over-complicated.

deleted 11mo ago
[deleted]
drnick1 11mo ago
Rust just doesn't work for a lot of applications. Things like GUI toolkits, Web browsers, game engines are a pain to write without true OOP. Yes, it's "overly complicated" at this point after about 40 years of development, buts it's still top 3 of the TIOBE index after all these years for a reason.
- ogoffart 11mo ago
  Of course Rust can handle those use cases fine (GUIs, web browsers, and game engines). C++ is still high on the TIOBE index mainly because it is indeed old and used in a lot of legacy systems. For new projects, though, there's less reason to choose C++.
  - drnick1 11mo ago
    It's still high because it solves real world problems, so it's still the gold standard for anything ranging from systems programming to scientific computing.
  - Calavar 11mo ago
    Web browsers, yes. With GUIs and games, it's a less clear. Of course you can write GUIs and games in any Turing complete language but there's still a lot of work to be done in finding the right ergonomics in Rust [1, 2]. [1] https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-ha... [2] https://loglog.games/blog/leaving-rust-gamedev/ https://loglog.games/blog/leaving-rust-gamedev/
    - koakuma-chan 11mo ago
      You are saying "With GUIs and games" as if there is any GUI framework or game engine that doesn't suck.
  - deleted 11mo ago

amluto 11mo ago

IMO destructive move is rather tangled up with another language feature: the ability to usefully have a variable of type T where all values must be actual values that meet the constraints of a T. Suppose T is a file handle or an owning pointer (like unique_ptr), and you want to say: T my_thing = [whatever] and you want a guarantee that T has no null value and therefore my_thing is valid so long as it’s in scope. In C++, if you are allowed to say: consume(std::move(my_thing)); then my_thing is in scope but invalid. But at least C++ could plausibly introduce a new style of object that is neither copyable nor non-destructively-movable but is destructively movable. Interestingly, Go is kind of all in on the opposite approach. Every instance of: my_thing, err := [whatever] creates an in-scope variable that might be invalid, and I can’t really imagine Go moving in a direction where either this pattern is considered deprecated or where it might be statically invalid to use my_thing. I actually can imagine Python moving in a direction where, if you don’t at least try to prove to a type checker that you checked err first, you are not allowed to access my_thing. After all, you can already do: my_thing: T | None = [whatever] and it’s not too much of a stretch to imagine similar technology that can infer that, if err is None, then T is not None. Combining this in a rigorous way with Python’s idea that everything is mutable if you try hard enough might be challenging, but I think that rigor is treated as optional in Python’s type checking.