I fixed it but I will bench mark it tomorrow:https://godbolt.org/z/5nvfj473e
. Sorry for thinking this one was a compiler bug, like it was just the copy
constructor being shadowed by a template constructor. It feels really dumb
now that I think of such a mistake.

On Tue, Apr 21, 2026 at 6:39 PM Muneem <itfllow123_at_[hidden]> wrote:

> Also by the way, I was getting the same array for just 2 elements, like a
> whole weird trace that I am gonna try my best to solve tomorrow.
>
> On Tue, Apr 21, 2026 at 6:20 PM Muneem <itfllow123_at_[hidden]> wrote:
>
>> Short answer: give me one more day to come up with the benchmarks and the
>> answers.
>> long answer:
>> I will back myself with benchmarks tomorrow. I couldn't do it today
>> because I spent too much time trying to debug my code using visual studio
>> 2026 but then I realized that the errors that I was debugging were from a
>> bug in visual studio 2026 regarding template metaprogramming. Like the
>> issue with visual studio 2026 is that the AI is misleading(ruins your code)
>> but even worse: sometimes your code compilers and sometimes doesn't not,
>> even while the code always compiles in Godbolt. All I can say now is that
>> the issue is that heterogeneous lists are used like tuples are used, and
>> its not better to use reflectors or complex code to index tuples using
>> runtime indexes, like in my case, Godbolt is throwing "tuple constructor
>> not found": https://godbolt.org/z/ee8o8fzfh . I will spend tomorrow
>> trying to fix it but relying on users to implement everything is
>> frustrating. Like code in my pdf file works sometimes on visual studio 2026
>> and sometimes doesn't, but always works on Godbolt, so the point is that
>> users want a standard interface so that they don't have to implement and
>> debug it themselves. Not everyone is willing to spend their whole day
>> reinventing the wheel. Most people don't care if there is an bug in the
>> compiler or something that causes issues. Again, I am sorry that I haven't
>> finished the benchmark code yet but I am working on it. I wont use C++ to
>> benchmark but rather some specialized tool, the benchmark code is to take
>> into all specializations possible, in fact I will. I couldn't find enough
>> time to do it today because I was reading the bash manual, and I thought
>> that this code(in the way I envisioned) would be extremely easy to write,
>> but when I sat late, I realized that I was in for the trenches.
>>
>> On Tue, Apr 21, 2026 at 12:05 PM Tiago Freire <tmiguelf_at_[hidden]>
>> wrote:
>>
>>> This is how this paper should have died.
>>> Why?
>>>
>>>
>>> In no circumstances have I ever found myself with:
>>> "I have a random index, I want to use it to index into a thing that has
>>> a bunch of different types of data, to do..." what specific thing exactly?
>>>
>>> Like seriously. What is the point of this?
>>>
>>> ------------------------------
>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on
>>> behalf of Muneem via Std-Proposals <std-proposals_at_[hidden]>
>>> *Sent:* Friday, April 17, 2026 4:26:29 AM
>>> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
>>> *Cc:* Muneem <itfllow123_at_[hidden]>
>>> *Subject:* [std-proposals] Extension to std::tuples to allow runtime
>>> indexing.
>>>
>>> Abstract: This proposal provides a specialization of std::tuple that can
>>> be indexed at runtime. It also introduces specializations for std::variant
>>> and std::optional to ensure the interface of such a tuple remains efficient.
>>> I wrote 3 files, the first was a complete draft that I am gonna paste as
>>> a txt file, the second was a formatted docx file that I wanted to float
>>> around the internet to get some feedback before I post it over here (sadly
>>> no on was interested in the poor man's document), and the third is the
>>> shortened version where I removed all the code and kept it conceptual.
>>> Sorry for pasting three files at once, but I just wanted to see which one
>>> is acceptable and which one isn't. Personally, I like the first two.
>>>
>>