On Thu, Jan 29, 2026 at 8:02 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Thu, Jan 29, 2026 at 10:05 PM Bo Persson wrote:
> >
> > > 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.
> >
> > So "is_often_trivially_copyable" ? Doesn't sound too useful.
>
>
> Well for one, this is useful for copying any kind of container, as the
> elements inside a container will always be the most-derived class. If
> you have std::vector<MyClass>, then when you copy the container,
> MyClass will be memcpy'able even if it's polymorphic. A polymorphic
> class is only non-copyable when you're dealing with a base object
> (i.e. not the complete object). If the class is marked 'final' then
> that's an assurance that you're dealing with the most-derived object
> and therefore that it can be memcpy'ed.
>
> I have shared the information contained in the above paragraph about 5
> or 6 times now in this thread.

You could find an actual real-world use case, rather than the
contrived hypothetical you insist on repeating. I mean, you did put
forth a good-faith effort to find one, only to then realize it didn't
fit. But then you stopped trying, as if that would make the question
go away.

> It's only the arm64e architecture that makes this impossible . . . but
> since the committee briefly entertained the idea of "restart_lifetime"
> to re-sign the vptr, then maybe it would also entertain
> "copy_lifetime". It's not like I'm inventing something new and
> mysterious here, even though it does warp the meaning of the word
> 'trivial'.
>
> I don't see why this conversation is going in circles . . . I mean
> there's some really intelligent people here on this mailing list. And
> I also don't understand why Jason is hellbent on maintaining the
> Standard's inaccuracy that all polymorphic objects cannot be
> memcpy'ed. If you don't believe me just try it out:
>
> https://godbolt.org/z/bv47vd9xT

You've been told several times that pointing at an implementation is
not a valid justification for a change in the standard. All it proves
is that the change is possible; the question is whether or not it is
*warranted*. You need to recognize the difference between those two
things and to engage with the one that is actually being asked.

You're coming very close to the strawman fallacy, where you
deliberately mis-state the opposing argument in order to defeat the
strawman version of it that you have corrected.

> The Standard inaccurately classifies all polymorphic classes as not
> trivially copyable even though a lot of them are trivially copyable.

The standard cannot be "inaccurate" to its own definition. Polymorphic
types are not trivially copyable by *fiat*; they are so because the
standard says so. There is no definition of this term outside of the
standard. Again, you may have notions as to what it *should* mean, but
that's a different thing from what it *does* mean.

What you want is to *change the definition*, to create a new
definition that encompasses types that don't fit the current one. This
is not a defect in the standard; it's a feature request. And a poorly
motivated one.