I provided explanations based on 'static' and 'constinit' which alleviate
the problem you mention. With 'static' alone the array would only be
created once at runtime which in amortized cost is still O(1) (this is how
"amortized cost" works). I agree that this is not the most optimal
solution, which is why constinit does the initialization at compile time.

Nothing has to be done "on the fly" in my solution. I'm not sure if you
don't know the intricacies of C++ yet or if you don't read carefully what
I've written (please take your time to read our posts more carefully!). I
assure you: It is possible with a lookup table for the offsets to write an
efficient solution which is about as fast as your solution (and definitely
O(1) at runtime). There might be a difference of 1 or 2 CPU instructions,
but it would certainly not be a bottleneck.

Just to be clear: I don't think that your solution is bad, but I do think
that it is unnecessary because it basically duplicates std::tuple with
additions that actually don't make it faster for this specific use case.

On Mon, Apr 20, 2026 at 3:29 PM Muneem via Std-Proposals <
std-proposals_at_[hidden]> 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 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>