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
>