The issue is that implementors dont want flexibility; they want more
vocabulary, and providing specializations that are based on tags in the std
namespace are the only way to do so. Vocabulary is why vectors, maps,
lists, and the likes exist. The techniques you were kind enough to teach me
were techniques for the user to use, and what I want is the standard to
provide an interface that I can simply use like vocabulary in my code and
can understand exactly what it does by just a look at it, such a "almost
container"(as bjarne stroustrup puts it) must be an implementation defined
balance, rather than for a specific purpose.
(philosophical answer):
The main motivation is that most C++ programmers dont know how the memory
is actually mapped on every system that they write code for. A book on some
rudimentary details of the linux kernel took me 3 months to read the first
100 pages of when I was 15, and even that only took me so far as to learn
how scheduling and processes work. The same is true for all developers, so
what you said could have been true back in the 90s where systems were
relatively simple, but now they are just a mess, especially thanks to
Windows not supporting the POSIX API properly. In fact, the Posix API took
me 3 months to understand and even then I couldn't write code for specific
low level tasks, which again further proves my point that existing compiler
infrastructure do it better at navigating this mess.

On Fri, Apr 17, 2026 at 6:56 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> If implementers would ask for flexibility or you would provide examples
> how on the list of types one or the other storage layout would be
> advantageous, it could make sense to give flexibility.
>
>
>
> But in your arguments you just assume that it helps in any way to give
> flexibility of implementation here. That is a bit of stretch.
>
>
>
> I would recommend to choose yourself one of the general 3 ways I presented
> and then concentrate on improving C++ that that way is easy to use, either
> by extending existing or creating new classes.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Fr 17.04.2026 15:47
> *Betreff:* Re: [std-proposals] Extension to std::tuples to allow runtime
> indexing.
> *An:* std-proposals_at_[hidden];
> *CC:* Muneem <itfllow123_at_[hidden]>;
> 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.
>
> On Fri, Apr 17, 2026 at 6:44 PM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> On Fri, Apr 17, 2026 at 9:37 AM Muneem via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > 1. I am not stating that book keeping is obligatory, but rather the
> implementation has that choice to make, and as we know the implementation
> knows more than us.
>
> This is fallacious reasoning. Compilers can know a lot, but they
> cannot know everything. And the performance implications of object
> layout cannot be fully known without a global analysis of how you're
> using the object. Which compilers *cannot* do.
>
> Even if they could, compilers cannot see code you haven't written yet,
> so that answer can change. It also cannot see code other people have
> written, so it has to make a decision without being able to see *any*
> of the code's usage.
>
> You're effectively saying that a compiler can tell whether a
> `deque<T>` or a `vector<T>` would be the better implementation to use
> for a given `T`, so `vector<T>` should be able to pick which
> implementation internally that it uses based on `T`.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>