Date: Mon, 20 Apr 2026 17:19:34 +0200
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.
This brings it back for me to teachability (which in my understanding is
important for standardization: we want to make C++ simpler and not harder).
I don't think that a new type with only minor differences (if you don't
look under the hood–and most programmers never do–the only difference to a
tuple is operator[]) improves teachability.
We see that there are many ways to implement this operator[] efficiently.
Muneem seems to take this that the compiler should "randomly" pick any of
these. Everybody else seems to see it as "a new type is not necessary".
>
> It's a memory vs. performance tradeoff, so you need to look at the
> downsides too.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/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.
This brings it back for me to teachability (which in my understanding is
important for standardization: we want to make C++ simpler and not harder).
I don't think that a new type with only minor differences (if you don't
look under the hood–and most programmers never do–the only difference to a
tuple is operator[]) improves teachability.
We see that there are many ways to implement this operator[] efficiently.
Muneem seems to take this that the compiler should "randomly" pick any of
these. Everybody else seems to see it as "a new type is not necessary".
>
> It's a memory vs. performance tradeoff, so you need to look at the
> downsides too.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2026-04-20 15:20:16