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.

On Mon, 20 Apr 2026, 7:14 pm Bjorn Reese via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On 4/20/26 15:29, Muneem via Std-Proposals wrote:
> > The issue with your code is that it keeps on making arrays on the fly. I
> > know the compiler has no issue optimizing it but relying on
> > optimizations isn't a positive thing, like vectors provide complexity
> > gurreenties instead of relying on optimizations. In your case the
> > complexity of is O(N) because you keep on making an array on the fly.
> > Further more the indexes that you used were constexpr not runtime. In my
>
> Let me modify my code slightly so it does not optimize the look-up table
> away:
>
> https://godbolt.org/z/Eo5GosPMj
>
> The lookup table is constructed at compile-time and stored globally
> in line 42 of the assembly output. There is no on-the-fly construction.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>