1.Your code is really genius, like I am little uninformed on newer c++
features since I am trying to also learn Bash, Ada, and how compilers work,
so I am really sorry if my level of c++ sometimes misinterprets parts of
pseudo code as "some abstract symbol", like that's what constinit looked
like.
2. I really believe that we should do bench marks, where I will provide
some new code that with have variants right next to tuple elements. The
tuple elements would be large and the benchmarks would be on array of those
large tuples. Is that an acceptable technique?

On Mon, 20 Apr 2026, 6:39 pm Simon Schröder, <dr.simon.schroeder_at_[hidden]>
wrote:

> 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
>>
>