1. The fact that strings were improved says a lot. It proves that no user
defined code is always right, and unlike the user, the standard can change
your code on a large scale and actually fix it if it makes a mistake,
whereas the user usually can't for large projects(even with these modern AI
based tools).
2. My point was that performance isn't straightforward, it depends on a lot
of factors, hence the standard library only gives out space and runtime
gurrenties. I dont want to continue defending myself on paging since I am
not that much into operating systems, sorry for bringing it up (my
perspective was to look at it from a larger perspective).
3. Again, vocabulary is important, and if you dont like to be confined
within the "terms and services" of what it provides then you can always
write your own. Just because you can write your own does not null the idea
of the importance of vocabulary. As bjarne stroustrup puts it multiple
times that you can build your own version of standard library facilities
but then you will have to maintain them and document them.
4. Vocabulary is a magic wand because as bjarne stroustrup mentioned in his
podcast with Lex friedmen: there was a guy who compared C and C++ code, the
C++ code was way shorter than the C code(which kept on expanding). Again,
the user generally dosent know much about what's best, hence in 99 percent
of the cases, he wants the standard to take over, but in some cases, he
might want himself to do the task. The point is that we have an
infrastructure that can provide mechanics better than we can. Our
optimizations might help make our code faster or smaller in one way but
their framework makes it balanced in all ways.

On Fri, Apr 17, 2026 at 7:33 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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 mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>