P3236R0
Please reject P2786 and adopt P1144

1. Why not P2786?

In P2786, types with user-provided operator= are reported as trivially relocatable by default. It’s incorrect to target these types for memmove optimization in vector::erase, rotate, and swap, since they don’t behave value-semantically. But P2786 gives no way to distinguish these types like tuple<int&> from ordinary trivially relocatable types like unique_ptr<int>. We cannot use P2786’s type-trait.

We all use is_trivially_copyable as our baseline: we assume that every trivially copyable type can be trivially relocated. In P2786, the programmer is allowed to create a type that is trivially copyable but not trivially relocatable. We prefer P1144’s simpler model, in which "trivially copyable types" is a proper subset of "trivially relocatable types."

In P2786, it’s ill-formed to create a trivially relocatable type with an offset_ptr member, or even a Boost static_vector member. P1144 considers these use-cases so important that they form 40% of its "Design goals" section. P2786 doesn’t offer a migration path for existing libraries at all.

In P2786, there is no backward-compatible syntax for marking a type trivially relocatable. P2786 proposes a new keyword trivially_relocatable, and goes out of its way to make the keyword unusable in C++23-and-earlier. P1144 simply uses an attribute, similar to [[noreturn]], which lets us enable our optimizations in all language modes. Our libraries are widely used pre-C++26. We look forward to using P1144’s marking syntax, but we cannot use P2786’s.

P2786 is deliberately incomplete. This makes it hard to reason about. It is a chess problem with multiple potential "lines" of development. In contrast, P1144 is a complete proposal, with an optimizing implementation publicly available since 2018. P1144 in its current state is acceptable to us.

P2786’s authors have drafted followup papers including P2959R0 and P2967R0, all with incomplete wording, attempting to fix some of its problems. P2959R0 proposes "heroic" changes to the semantics of library containers, for example std::container_replace_with_assignment to customize the behavior of vector::erase. We don’t want new semantics for containers. We want safety and reliability for the optimizations we are already doing, with the semantics we already have.

2. Why P1144?

P1144 provides useful semantics for is_trivially_relocatable.
Every signatory to this paper desires P1144 semantics (not P2786 semantics) in our libraries.
P1144, by providing stronger guarantees of value semantics, permits more optimizations:

P1144 provides a stable library API that some signatories have already implemented. It is well-designed and consistent with the rest of the STL. P2786 proposes only one library function — a constrained std::trivially_relocate — with no implementation experience. As algorithm authors, we do not want P2786’s library function; it is not useful to us.

P2786’s warrant marking can be used only if all bases and members are themselves trivially relocatable; this makes it "viral downward." As container authors, we think P2786’s normalization of a large number of explicit markings will cause programmer fatigue and lead to bugs. We support P1144’s approach, which requires explicit markings only in the places that the library programmer directly exposes to the client, where invariants are clearest and audits are simplest. Compare how the two proposals handle the following optional-like type:

template<class T>
struct OptlDetail trivially_relocatable {
  // ...
  ~OptlDetail();
};
 
struct OptlPiece trivially_relocatable {
  // ...
  OptlPiece(OptlPiece&&);
};
 
template<class T>
struct Optional trivially_relocatable\
(is_trivially_relocatable_v<T>)
    : private OptlDetail<T> {
  OptlPiece m_;
  Optional(Optional&&);
  ~Optional();
};

template<class T>
struct OptlDetail {
  // ...
  ~OptlDetail();
};
 
struct OptlPiece {
  // ...
  OptlPiece(OptlPiece&&);
};
 
template<class T>
struct [[trivially_relocatable\
(is_trivially_relocatable_v<T>)]]
    Optional : private OptlDetail<T> {
  OptlPiece m_;
  Optional(Optional&&);
  ~Optional();
};

3. Signatories

We ask that WG21 reject [P2786] and adopt [P1144] instead.

• Amadeus AMC: Stéphane Janel

• Blender: Hans Goudey

• Blender: Jacques Lucke

• Boost: Alan de Freitas

• Boost: Krystian Stasiowski

• Carnegie Mellon Parlay: Daniel Liam Anderson

• Qt Project: Giuseppe D’Angelo

• Qt Project: Thiago Maciera

• Ste||ar HPX: Hartmut Kaiser

• Ste||ar HPX: Isidoros Tsaousis

• Ste||ar HPX: Shreyas Atre