On Sat, Jan 24, 2026 at 5:58 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sat, Jan 24, 2026 at 9:23 PM Jason McKesson wrote:
> >
> > Sprites are not images; they *use* images.
>
>
> Yeah you're right I've never worked on 3D computer graphics and I'm
> not even really sure what a Sprite is.
>
> The sample class I gave was just an example of a class that has much
> more data than metadata. A better example might have been a class that
> contains several 512-byte RSA key pairs.
>
> Anyway my argument still stands: The 'memcpy' optimisation for
> copy-construction should be usable for polymorphic types (so long as
> A: the class is final, or B: we're guaranteed to be dealing with the
> most-derived object).

No, your argument doesn't stand. It doesn't have a non-contrived use case.

Why would a class simultaneously 1) contain "several 512-byte RSA key
pairs", 2) not otherwise be disqualified from bytewise-copies, 3) be
polymorphic, and 4) need to be byte-wise copied frequently enough for
this many changes to the standard to be worthwhile? When does this
happen in real applications?

Saying that a class *could* contain these things, that these
circumstances *could* occur is speculation. What real-world
applications would this actually be useful in?