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. 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.

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

> On Fri, Apr 17, 2026 at 9:47 AM Muneem via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > What I meant is the choice is based on the implementation's reasoning on
> how runtime indexing should be done. Basically, it wont choose between
> deque or vector, it will choose one that is fit for runtime indexing and
> stick to it. Currently, what It sticks to is efficient only for space since
> the main goal is to provide compile time indexing.
>
> My point is that it's not an either/or thing. Needing runtime indexing
> is a static choice; you know at some point that you need to index the
> tuple at runtime. That's core to the code you're writing.
>
> But whether you need runtime indexing to be fast (again, ignoring
> whether the bloated version is *ever* actually faster, which you've
> yet to demonstrate) depends on how often you do it relative to
> size-based operations. If you need the size-based performance, but
> also need runtime indexing, what do you do?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>