[jandrewrogers]

C++26 adds destructive moves. They are called relocatable types.

There are edge cases where destructive moves are not safe and it is impossible for the compiler to know they aren't safe. C++ uses non-destructive moves when it can't prove the safety of destructive moves, even if destructive moves may in fact be safe. C++26 adds a type annotation that guarantees destructive moves are safe in cases where you can't prove they are un-safe.

The concept of relocatable types is actually a bit broader in scope than just destructive moves, but destructive moves are one of the things it enables. It is a welcome change.

[aw1621107]

> C++26 adds destructive moves. They are called relocatable types.

I thought those were removed? For example, see Herb's 2025-11/Kona trip report [0]:

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

[0]: https://herbsutter.com/2025/11/10/trip-report-november-2025-...

[jandrewrogers]

Good catch, very possible. I was surprised to see it listed as included when I searched. It may be stale information.

[affenape]

From the proposal, I see a bunch of new keywords and rules - alright given the language's heritage. But what happens if I "relocate" a variable value - would a "shell" remain or how exactly C++ is supposed to handle this:

  auto value = create_value();
  if (some_cond) {
    consume_value(std::move(value)); // not sure whether it's move here, but I guess my point is clear
  }

  use_value(value);

[jandrewrogers]

My assumption is that this would produce a compiler error. Depending on whether or not the branch is taken, you would essentially be accessing an uninitialized value. Compilers already catch this type of case.