I am really really sorry for my late response ( i was trying to write code
for benchmarking (shown at the end of my email)). My response to the
assumptions that the standard should let the user choose between code bloat
or otherwise, and that the compiler dosent need complete freedom is that
the standard can and should provide speed and space complexity guarantees,
that's all it is meant for. A new type is important, not only to make sense
of these gurrenties but also optimize. The benchmarks of my code in
comparison with Bjorn's show it. I couldn't use Simon's code though since
It was in his words "the idea of it" and honestly, I thought it would be
disrespectful to assume what his actual implementation would look like.
Sebbastian is right that the compiler can in fact remove tables if they are
unused, and in my case, but I would like to add that doing so by relying on
"global life time objects"(lack of a better word), leads to you thrashing
cache (the bookkeeper isn't always gonna be near every tuple).
Here are my benchmarks that do optimize indexing of the book keeping array
but even then as shown, The speed is the same but the size of the assembly
is larger in Bjorn's case:
benchmarks:https://quick-bench.com/q/SXhNQtb3TvxaDbc8Wx_P8OvMQYQ
My code:https://godbolt.org/z/rcvaYK9Wa
Bjorne's code:https://godbolt.org/z/rPvdGvoh9
Note: I wrapped both of our codes in a type, but the underlying interface
of the [] operator differed. In Bjorne's case the class only stored a tuple.
In the following days, I will try to find more benchmarking data and more
facts/arguments to the table.
Summary of my argument today is that a new type means that you have control
over the object layout of each object hence every book keeping information
can be right inside the object if that's faster (if the compiler says so).


On Tue, Apr 21, 2026 at 5:19 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, Apr 20, 2026 at 11:20 AM Simon Schröder
> <dr.simon.schroeder_at_[hidden]> wrote:
> >
> > On Mon, Apr 20, 2026 at 5:08 PM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >> On Mon, Apr 20, 2026 at 10:52 AM Muneem via Std-Proposals
> >> <std-proposals_at_[hidden]> wrote:
> >> >
> >> > Give me sometime to understand your code and respond. I will also
> write some extra possible implementations for the proposed tuple type
> tomorrow and run bench marks against Mine, your's, and Simon's code. I am
> confident mine is faster by a large margin since I can choose any
> implementation, which is to prove that a new type with a new implementation
> is good because the compiler can choose any implementation. Of this
> ofcourse would be just talking until I provide some numbers to back myself
> up.
> >> >
> >> > Billions thanks to everyone for their feedback.
> >>
> >> Note that it cannot just be faster at random access. You also have to
> >> look at how much slower it is at copying, or iterating through
> >> sequences of them due to the excess bloat in the type.
> >
> >
> > This would basically make Muneem's type *not* zero overhead. Because you
> would pay for the overhead of bookkeeping even if you don't use operator[].
> One could argue though, that one should only use Muneem's new type when
> wanting to access operator[] and use std::tuple in all other cases.
> However, this would make it unnecessarily harder if someone wants to switch
> later.
>
> My main issue is having to choose. If you want runtime indexing, you
> *have* to choose this size bloat. If you don't want the size bloat,
> you *have* to choose no runtime indexing.
>
> Whether there's a new type or not, the interface should still work on
> a `tuple`, even if it is at reduced random access speed (though again,
> there's no evidence of that yet).
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>