On Thu, Jan 29, 2026 at 4:47 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Thu, Jan 29, 2026 at 4:37 PM Thiago Macieira wrote:
> >
> > Right now, we don't need to do anything because no polymorphic
> > object can be trivially copied.
>
> This one can:
>
> struct Donkey final {
> ~Donkey(void) noexcept = default;
> int n;
> };
>
> Are you making a distinction between "The Standard says it cannot be
> trivially copied" and "In actual fact it cannot be trivially copied"?
> Because these are two different things. According to the Standard, no
> polymorphic object can be trivially copied. However in reality, on
> every implementations except for arm64e, the vast majority of
> polymorphic objects can be trivially copied so long as they're either
> 'final' or guaranteed to be the complete object.

The very term "trivially copyable" is defined by the standard.
`Donkey` is not trivially copyable because it has properties that
aren't allowed for a type to be in the classification of "trivially
copyable types".

Perhaps you have some private definition of "trivially copyable", some
notion that exists outside of the standard definition. But your
personal definition has no bearing here.

You want such types to be trivially copyable. But you don't want to
give an actual reason as to why they should be besides "well, I can
implement it in a way that would make it theoretically functional on a
compiler."

It is not the job of the standard to align with anything that a
compiler *could* do. The job of the standard is to help programmers,
and thus far, you have given not a single practical reason why
programmers would actually be helped by adopting your definition. The
closest thing to a practical justification you've given is a
confluence of circumstances that you can't even verify that someone
has actually encountered.