C++ Logo

std-proposals

Advanced search

Re: [std-proposals] is_trivially_copyable_in_reality

From: Thiago Macieira <thiago_at_[hidden]>
Date: Fri, 23 Jan 2026 18:41:04 -0800
On Friday, 23 January 2026 17:50:12 Pacific Standard Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> 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;

It's still a new trait by another name. It doesn't negate my argument that we
don't need this new query in the first place.

And it's only worse when we consider you want it to be non-cross-platform. I
think that's a DOA request.
 
> 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.

This is probably a deal-breaker.

> > 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.

No, we can't standardise what isn't common.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.

Received on 2026-01-24 02:41:13