Date: Fri, 23 Jan 2026 09:48:35 -0500
On Thu, Jan 22, 2026 at 5:55 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I've been searching for a few hours and I can't find one example of a
> class that has a default copy constructor and a non-trivial
> destructor. Not even one.
[...]
> I do not see the logic in why the committee decided that a trivially
> copyable type must have a trivial destructor, and so unless someone
> can convince me of otherwise, my new trait
> "is_trivially_copyable_in_reality" will disregard destructors
> altogether.
>
You're thinking about it backwards. Let's agree that types with a trivial
copy constructor and a non-trivial destructor are "stupid types." Now,
suppose some user-programmer writes a "stupid type." Do we *need* that type
to be recognized by your trivially-whatever-in-whatever trait? No, of
course not. The trait's answer doesn't matter for "stupid types," because
nobody should be writing such types in the first place, and if they write
one and pass it to your trait, they'll deserve whatever answer they get.
Therefore, it is perfectly fine for your trait to reject "stupid types" and
give the answer `true` only for well-behaved types.
(The nomenclature "stupid types" I owe to Thiago Maceira and Corentin Jabot
here <https://github.com/llvm/llvm-project/pull/84621>. ;))
This is the logic taken by today's `is_trivially_copyable` (more or less —
see P3279R0
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3279r0.html> for
some corner cases), and by P1144 `is_trivially_relocatable`. The logic is,
we want the trait to give the answer `true` when a certain
optimization is *known
to be safe* for a *well-behaved* type. If someone gives us a demonstrably
stupid type that already misbehaves *regardless* of how we answer, then it
is safest to answer `false`. Trivially-fooable is an optimization, and the
rule for user-programmers should always be "Make it correct, *then* make it
fast." Trait designers should not go out of their way to unlock fast-ness
for user types which have demonstrably not yet achieved correctness.
–Arthur
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I've been searching for a few hours and I can't find one example of a
> class that has a default copy constructor and a non-trivial
> destructor. Not even one.
[...]
> I do not see the logic in why the committee decided that a trivially
> copyable type must have a trivial destructor, and so unless someone
> can convince me of otherwise, my new trait
> "is_trivially_copyable_in_reality" will disregard destructors
> altogether.
>
You're thinking about it backwards. Let's agree that types with a trivial
copy constructor and a non-trivial destructor are "stupid types." Now,
suppose some user-programmer writes a "stupid type." Do we *need* that type
to be recognized by your trivially-whatever-in-whatever trait? No, of
course not. The trait's answer doesn't matter for "stupid types," because
nobody should be writing such types in the first place, and if they write
one and pass it to your trait, they'll deserve whatever answer they get.
Therefore, it is perfectly fine for your trait to reject "stupid types" and
give the answer `true` only for well-behaved types.
(The nomenclature "stupid types" I owe to Thiago Maceira and Corentin Jabot
here <https://github.com/llvm/llvm-project/pull/84621>. ;))
This is the logic taken by today's `is_trivially_copyable` (more or less —
see P3279R0
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3279r0.html> for
some corner cases), and by P1144 `is_trivially_relocatable`. The logic is,
we want the trait to give the answer `true` when a certain
optimization is *known
to be safe* for a *well-behaved* type. If someone gives us a demonstrably
stupid type that already misbehaves *regardless* of how we answer, then it
is safest to answer `false`. Trivially-fooable is an optimization, and the
rule for user-programmers should always be "Make it correct, *then* make it
fast." Trait designers should not go out of their way to unlock fast-ness
for user types which have demonstrably not yet achieved correctness.
–Arthur
Received on 2026-01-23 14:48:53
