Date: Fri, 17 Apr 2026 10:32:55 -0400
On Fri, Apr 17, 2026 at 9:59 AM Muneem via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Basically, there should be a standard version that balanced it, just like there is for strings that sometimes provides small string optimization, and if the user finds such standard balance unsatisfactory then he can build his own.
Your argument is historically false. To the extent that `std::string`
was designed to allow for optimizations, some of those optimizations
didn't work out. Copy-on-write implementations were something that
C++98 explicitly wanted to allow for, but as time progressed, it
became clear that these were bad ideas.
And undoing those ideas took a *long time*. C++11 had to forbid CoW,
and even then, libstdc++ took forever to break ABI to stop using CoW.
It's much better to have the functionality, see where performance can
be improved as the functionality gets used, and then offer up that
optimization possibly in a new type. Premature optimization and all
that.
> Again, the user generally cant fully optimize for space because modern operating systems are more complicated in that they have paging facilities that can lead to higher PHYSICAL memory usage even if the virtual memory usage is low, basically, the implementation knows how to avoid this, but as a programmer you dont. Infact, most C++ programmers would not know about the difference between virtual and physical memory and how paging works with these notions. The reason we switched from assembly and C to C++ is because we dont want to deal with such details.
You keep using these general statements to justify specific things,
but you don't actually provide meaningful evidence of the specific
thing you want.
For example, I don't know how paging or virtual memory have *anything*
to do with whether a tuple should have internal pointers to itself.
But I do know what the consequences are for having that:
1. Bloat. The type has to be bigger.
2. Trivial copyability and movement. The type cannot be trivially
copied and every copy will be slower than it could be because of
pointer fixup.
Are there cases where it may not matter? Sure. Does that mean that
runtime indexing *must* be tied to such bloat and slowness? No. It is
possible to reasonably implement runtime tuple indexing using
`std::tuple` as it exists. Everything *functionally* about the
mechanism of how runtime indexing as you've defined it can be
implemented in `std::tuple`. That feature should not be gated behind
this new type.
"Implementations should have optimization opportunities" is only a
meaningful justification for some feature if you can actually show
where it is meaningful for *that feature*. It's not a magic wand you
can just wave over any design choice to force others to accept it. It
must be justified by practical reality, not theory.
<std-proposals_at_[hidden]> wrote:
>
> Basically, there should be a standard version that balanced it, just like there is for strings that sometimes provides small string optimization, and if the user finds such standard balance unsatisfactory then he can build his own.
Your argument is historically false. To the extent that `std::string`
was designed to allow for optimizations, some of those optimizations
didn't work out. Copy-on-write implementations were something that
C++98 explicitly wanted to allow for, but as time progressed, it
became clear that these were bad ideas.
And undoing those ideas took a *long time*. C++11 had to forbid CoW,
and even then, libstdc++ took forever to break ABI to stop using CoW.
It's much better to have the functionality, see where performance can
be improved as the functionality gets used, and then offer up that
optimization possibly in a new type. Premature optimization and all
that.
> Again, the user generally cant fully optimize for space because modern operating systems are more complicated in that they have paging facilities that can lead to higher PHYSICAL memory usage even if the virtual memory usage is low, basically, the implementation knows how to avoid this, but as a programmer you dont. Infact, most C++ programmers would not know about the difference between virtual and physical memory and how paging works with these notions. The reason we switched from assembly and C to C++ is because we dont want to deal with such details.
You keep using these general statements to justify specific things,
but you don't actually provide meaningful evidence of the specific
thing you want.
For example, I don't know how paging or virtual memory have *anything*
to do with whether a tuple should have internal pointers to itself.
But I do know what the consequences are for having that:
1. Bloat. The type has to be bigger.
2. Trivial copyability and movement. The type cannot be trivially
copied and every copy will be slower than it could be because of
pointer fixup.
Are there cases where it may not matter? Sure. Does that mean that
runtime indexing *must* be tied to such bloat and slowness? No. It is
possible to reasonably implement runtime tuple indexing using
`std::tuple` as it exists. Everything *functionally* about the
mechanism of how runtime indexing as you've defined it can be
implemented in `std::tuple`. That feature should not be gated behind
this new type.
"Implementations should have optimization opportunities" is only a
meaningful justification for some feature if you can actually show
where it is meaningful for *that feature*. It's not a magic wand you
can just wave over any design choice to force others to accept it. It
must be justified by practical reality, not theory.
Received on 2026-04-17 14:33:09