On Sat, Jan 24, 2026 at 1:03 AM Thiago Macieira wrote:
>
> While that is true, I don't think the use-case suffices to add yet another trait
> in addition to is_relocatable or is_trivially_move_assignable.


Instead of adding a new trait, we can just take:

    template< class T >
    struct is_trivially_copy_constructible;

and augment it to:

    template< class T, bool guaranteed_complete_object = false >
    struct is_trivially_copy_constructible;

Then there will be two changes needed to the specification of
'is_trivially_copy_constructible':
1) When guaranteed_complete_object is false, the trait can still be
true so long as T is final
2) When guaranteed_complete_object is true, the trait can be true

This would not be any kind of ABI break, nor a break in backward compatibility.

I think I might be able to write this into the GNU g++ compiler within
a day or so. Basically I'd take the code for the built-in function
__is_trivially_copy_constructible and just remove the restrictions on
polymorphic objects (where T is final or where we're guaranteed to
have the complete object).

Of course, if __ARM64E__ or whatever is defined, then polymorphic
objects will never be memcpy'able . . . . . unless we bring in another
new function called something like "copy_lifetime" or
"clone_lifetime", which, similar to "restart_lifetime", would re-sign
the pointers.


> It can be a platform-specific optimisation (QoI) applied by some
> implementations, if they feel the need.


Yeah but we can also standardise an optimisation.