On Sat, Jan 24, 2026 at 2:13 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> On Saturday, January 24, 2026, Arthur O'Dwyer wrote:
>>
>>
>>
>> You seem to be reinventing the idea of a "copy constructor."
>
>
>
> I do see your line of reasoning here but let me get to the optimisation part.
>
> Let's say we have a 3D graphic class something like:
>
> struct Sprite : Entity {
> long double GetVolume(void) override;
> long long points[1024][1024];
> };

I find it so very telling that your go-to example for the utility of
what you're trying to make is of a programming idiom that is known to
be a terrible idea for the very specific use case you offer it up for.
Game entity hierarchies are basically the poster-child for when NOT to
use inheritance. And it's not like this is some hidden knowledge. This
has been known about and discussed for decades. There are whole
articles online for why this is a bad idea. Those discussions have led
to the development of an alternative idiom (component entity systems)
that was invented to specifically solve this particular class of
problem for this specific use case (ie: "entities"). Nobody remotely
knowledgeable in this space of software engineering would ever write
the code you've shown here.

Yet you just proudly show it off like this was reasonable code instead
of something that's been proven over decades of software engineering
experience to be a massive foot-gun.

It's telling because it shows that your idea is only useful for bad code.

> You'll agree here that the data part of this class is much much bigger than the potentially "not memcpyable" part of the class (i.e. 8 megabytes Vs 8 bytes).

Ignoring the fact that your very example is a software engineering
poster-child for "don't ever do this," even your example refutes
itself. Why?

Because nobody would store the image data for a polymorphic entity's
sprite inside the class instance.

Sprites are not images; they *use* images. They reference images that
live elsewhere. Even if you're not using the GPU to hold the image
data (for some reason), you still wouldn't put the image data in the
sprite class itself because multiple entities might want to use the
same image data. These should be pointers to data, not the data
itself. Possibly smart pointers, which means byte copying is off the
table (unless you're willing to make a lot of assumptions about the
lifetime of that image data).

> Now let's say we have a container of 6 million of these sprites, and we want to copy the whole container.

I've seen my fair share of entity hierarchies in actual live programs.
Not one of them had a base entity class that was correctly bytewise
copyable. Most of that code predates C++11 (and some of it dated to
before C++98), so you could technically copy them. But if you did so,
they'd be broken; copying an entity was a special operation that had
its own functions (or just wasn't supported at all because why would
you *ever* want to do that).

One of the reasons why bytewise copyability is generally off-the-table
for an entity is that they tend to reference *other* entities for
various reasons, and other entities reference them. These complex
relationships don't work when you just willy-nilly copy bytes around.

But let's ignore that for the moment.

So, our hypothetical programmer has a massive container of sprites.
And each hypothetical sprite actually contains 8 MB of image data for
some reason. And our hypothetical entity base class type is
conceptually bytewise-copyable.

Even with all that, what exactly is it that compels our hypothetical
programmer to decide to copy 48 MEGABYTES of data? Yes, the very
foundation of this example requires that our hypothetical programmer
is a multi-level idiot, but trivial or no, copying 48 MB is not
something you do just because. There has to be a compelling
justification for copying any data structure of that size, bytewise or
not.

So what is it?

I know all of these criticisms are specific to this particular use
case, but I bring them up because it makes a point. Specifically,
these defects show how little you're thinking about actual use cases.
It's like I'm reading examples from someone who's never actually been
a part of writing systems of significant complexity before. You're not
coming up with plausible justifications for the feature you want based
on your experience. You're just making off-the-cuff examples without
any care or attention as to whether those examples actually represent
code that a competent programmer would actually write.

Your entire justification seems to be that someone *could* do things
this way, and it'd be faster if they had more support for it, and it's
technically possible for implementations to do so; therefore the
committee should spend time making that faster regardless of how many
or few people it actually helps.

Not only can you not show one real-world use case for this feature, I
suspect you don't think you need to. That such questions are sophistry
that gets in the way of what features the language definitely should
have. Which is why you'll ignore everything in this post, just like
you ignored my previous one.

I would hope that, until you adequately address the relevant question
of providing a real-world justification for why someone would actually
want to do this, everyone would just ignore this thread. Granted, that
doesn't seem likely, but I'm hopeful that it will happen.