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 case, the goal is that the O(1)
gurrentie exist regardless of what type of index is actually used.

I am sorry that you feel like you have to mentor me but I am 17, so give me
some credit. Nevermind, Just joking, but yeah, I am sorry that you feel
that way though. Hope I can convince you to think otherwise.

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

> On 4/20/26 12:44, Muneem via Std-Proposals wrote:
> > The issue with creating on the fly is that it's painfully slow, like to
> > get O(1) performance, you need some book keeping information. To get
>
> I am not sure where you imagine this on-the-fly stuff occurs. The
> solutions I have presented build a compile-time look-up table. This
> table does not need to be a member of the tuple.
>
> This, like many of your arguments, focus on premature optimization.
> Consider the following implementation:
>
> https://godbolt.org/z/n47qveWcM
>
> Notices how the compiler has no problem optimizing this code even at
> the lowest optimization level.
>
> I do not know how to put this nicely, but these discussions feel more
> like mentoring than standardization.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>