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. ;))
This is the logic taken by today's `is_trivially_copyable` (more or less — see
P3279R0 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