I don't find those types so stupid. I gave an example with caches, but even just having debug messages inside the destructor could make the destructor non-trivial.   I hope those types get at most a performance penalty and not some unexpected behavior like the destructor not being called at the end of the lifetime.   -----Ursprüngliche Nachricht----- Von:Arthur O‘Dwyer via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 23.01.2026 15:49 Betreff:Re: [std-proposals] is_trivially_copyable_in_reality An:std-proposals_at_[hidden]; CC:Arthur O‘Dwyer <arthur.j.odwyer_at_[hidden]>; On Thu, Jan 22, 2026 at 5:55 PM Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden] <mailto: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. ;))  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 -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals