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.

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

The Standard inaccurately classifies all polymorphic classes as not
trivially copyable even though a lot of them are trivially copyable.
So this is more of a defect report than a proposal. And by the way
it's 2026 so we need to stop pretending that vtables don't exist -- I
realise that a compiler can implement virtual function dispatch
however it wants to, but every compiler uses vtables. At the very
least it should be implementation-defined (not "unspecified") as to
which polymorphic classes can be memcpy'ed. Actually, the Standard
should mandate that 'final' classes are trivially copyable (assuming
of course that they don't have some other property that takes away
their trivial-copyability). Then later we can decide what to do with
Apple Silicon.

Oh and by the way it was a good catch by Giuseppe that we were getting
bad assembler because of the lack of 'restrict'. I feel like I should
tell ChatGPT to go through my entire Github account through all the
repos to pick out places where __restrict might speed things up.