Again, I get your point, I really do, but the thing is that even if tuples
were slower:
1.you would call if microbenchmarks as it always happens on the list
2. It dosent matter because the goal is a new type for a new notions that
is different that product types(tuples). Basically it tries to extend the
notion/idea of product types. Building anything on the top of product types
to extend the notion is just dragging on baggage; It's a new type with new
ABIs.
3. I can't do benchmarks since variants of references dosent exist, so any
benchmark would be flawed since it would not include one the main aspects
of what makes my proposal efficient.

On Sat, 18 Apr 2026, 6:59 pm Giuseppe D'Angelo via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Hello,
>
> On 18/04/2026 12:48, Muneem via Std-Proposals wrote:
> > The point is that I tried to maintain as much detail as the standard
> > allows me because again, this is a standard proposal and being abstract
> > is important
>
> It's actually the exact opposite: being detailed and specific is more
> than important, it's essential.
>
> You need to show the cost of runtime indexing a std::tuple on today's
> implementations.
>
> You also need to show your re-engineered tuple, for which runtime
> indexing is faster/cheaper/better.
>
> This is the entirety of the argument, isn't it? That is: that you need a
> novel implementation in order to optimize the runtime indexing, and that
> the same performances can't be achieved in existing libraries, not
> without breaking ABI.
>
> Only once this argument is proven we can move discussing whether this is
> actually worth the addition to the standard library.
>
> The point is that without this _hard data_ the proposal is entirely
> vacuous. It's a wish for a magical thing, that no one even knows if it
> actually exists.
>
>
> > Implementation details and assumptions always lead to some incorrectness
> on all sides.
>
> It's the opposite. The argument "this is better" needs to be grounded in
> data, which requires showing the implementation details.
>
> My 2 c,
> --
> Giuseppe D'Angelo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>