On Fri, Jan 23, 2026 at 5:20 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I need to try re-frame this all over again. And I'm realising now that
> this was the missing step we needed toward settling on a final
> solution for relocation. We will never figure out relocation in C++
> until we figure out copying.
>
> First of all I'll be specific about what I'm talking about. Consider
> the following code that copies a vector:
>
> vector< MyClass > vec1;
> vec1.emplace_back( 1, 2, 3 );
> vec1.emplace_back( 16, 2, 3567 );
> vec1.emplace_back( 3234, 2, 333 );
> auto vec2 = vec1;
>
> The line immediately above copies an entire vector. This process will
> involve two things:
> A) allocating memory
> B) copying objects
>
> As an optimisation for B, I want to use 'memcpy' instead of running a
> loop with 'construct_at'. But in order to be able to determine when I
> can use this optimisation, I need a new trait. Right now the Standard
> only has 'is_trivially_copyable' for this purpose but it needlessly
> reports that all polymorphic objects cannot be memcpy'ed (even though
> most of them can -- except for on arm64e). So we need a new trait.

No, we don't.

See, we only "need a new trait" if there's a reason why we need to be
able to memcpy objects that are not considered trivially copyable
under the current rules. So the first thing that needs to be addressed
is this:

Why is that important?

Once we establish that it's actually important to be able to memcpy
such objects, we then need to establish the set of circumstances where
that's a reasonable thing to do. But until we've finished step 1, I
don't feel like the other steps are worth taking.

So why do we need to trivially copy polymorphic types? Why is this an
important thing for programmers to be able to do?