1.The issue with switch case statements is the lack of gurrenties.
2. Multiple tuples with the same T... (In others: Same specialization)
Could then share the same book keeping information, leading to a
modification to one resulting in modification to all.
3. The offsets cant be the same exactly because duplicates will exist, so
you can try to make them stable to a certain extent but you can't exactly
do that, since tuples can and should have two objects of the same type but
a variant can't have two same types according to the current c++ standard.
4.I am not breaking the ABI of existing tuples, infact I am proposing a new
type. I used the name tuple to make my code shorter and readable.
5. The issue with adding a new type is too much Boilter plate because you
would have to use that and annoying hardwork to keep track of which object
of that type corresponds to which tuple, this hardwork if not done well can
lead to undefined behavior if you use the wrong book keeper with the wrong
tuple.


A billion thanks for your feedback, I really appreciate it.

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

> Everyone agrees that we want O(1) performance. Even with a
> switch-statement O(1) is possible (but not guaranteed with current
> compilers, but it fits the "compiler should decide which is more optimal").
> But, Sebastian already suggested a different solution using stored offsets.
> This could look something like this:
>
> template<class Ts...>
> const std::variant<Ts&...> std::tuple<Ts...>::operator[](std::size_t index)
> {
> static constinit void offsets[sizeof...(Ts)] = [](){ /* compute
> offsets */ }();
> return std::variant<Ts&...>(*this + offsets[index]);
> }
>
> This code does not compile right now, but it shows the general idea. We
> can make the offsets a static variable which is initialized at compile-time
> using a immediately invoked lambda. Basically, this can be understood as
> storing bookkeeping information inside operator[]. We can do this because
> this function is instantiated for every combination of Ts... (if they are
> used) and has its own static variable. And the offsets will be the same if
> the types of the tuple are the same in the same order. No need to break the
> ABI of existing std::tuple.
>
> Alternatively, we could create another type
> std::detail::tuple_bookkeeping<Ts...> (something hidden, not standardized)
> which could also just have the offsets stored. There is no runtime overhead
> to get the offsets.
>
> Both solutions (static variable or tuple_bookkeeping) are O(1). Best
> advantage: Standard library implementers don't have to change the ABI and
> they don't have to maintain two different types (the existing std::tuple
> and your new type) in the future. This also means fewer bugs in the
> standard library.
>
> On Mon, Apr 20, 2026 at 12:45 PM Muneem via Std-Proposals <
> std-proposals_at_[hidden]> 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 that
>> book keeping information, I need a new type. The goal is one: speed and to
>> get speed, I can't change existing tuples to include an array of variants<
>> T&...> .
>>
>> Recursive defintion was just an example of what implementors normally do
>> and what makes sense to do with existing variadic template facilities.
>>
>> The goal isn't a syntactical construct but a new type with O(1)
>> complexity. The standard can gurrentie complexities:
>> https://en.cppreference.com/cpp/container/vector
>>
>> The O(1) complexity along with constexpr construction is all that most
>> users would care about for subscripting tuples. Syntaxtical sugar is
>> something that with "template for" or (maybe) even existing features could
>> be done.
>>
>> Thanks for your response, I really Appreciate it.
>>
>> On Mon, 20 Apr 2026, 3:24 pm Sebastian Wittmeier via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> I get where you are coming from.
>>>
>>> Just propose a runtime dynamic index for the existing std::tuple. The
>>> implementors will take care of it and it will be fast.
>>>
>>>
>>>
>>> Also creating a std::variant to a pointer or (extended to a reference)
>>> on the fly will be fast. No need to put a pre-created std::variant copy
>>> into the tuple or array.
>>>
>>>
>>>
>>> The recursive definition will not matter for the runtime-speed or
>>> optimization potential. That is the implementors' job.
>>>
>>>
>>>
>>>
>>>
>>> It could (!) be that some implementations are slow *at compile-time* for
>>> very long heterogeneous lists implemented with std::tuple. In this case
>>> that is not a topic for the standard (nothing it could do to help), but for
>>> the implementations to optimize their compilation.
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
>>> *Gesendet:* Mo 20.04.2026 11:01
>>> *Betreff:* Re: [std-proposals] Extension to std::tuples to allow
>>> runtime indexing.
>>> *An:* std-proposals_at_[hidden];
>>> *CC:* Muneem <itfllow123_at_[hidden]>;
>>> It is not relevant, but mentioned it to just say that their existing
>>> structure is normally just a dumb recursion which is perfect for compile
>>> indexing, but not for complex optimizations that are to reduce a runtime
>>> indexing operator to 0(1) complexity.
>>>
>>> I am sorry that I didn't reply to all the previous responses, I was a
>>> little tired from writing the code.
>>>
>>> On Mon, 20 Apr 2026, 1:41 pm Sebastian Wittmeier via Std-Proposals, <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>> Is it relevant, whether tuples are recursively defined, or not?
>>>
>>> It is the programming style for functional programming.
>>>
>>> Doesn't mean that indexes are resolved recursively at runtime.
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
>>> *Gesendet:* Mo 20.04.2026 10:03
>>> *Betreff:* Re: [std-proposals] Extension to std::tuples to allow
>>> runtime indexing.
>>> *An:* std-proposals_at_[hidden];
>>> *CC:* Muneem <itfllow123_at_[hidden]>;
>>> Sorry for sending too many emails at one( I really am ):
>>>
>>> https://github.com/HjaldrKhilji/Future-potential-ISO-porposals/blob/main/Runtime_Indexed_Tuples_Proposal_Official%20(1).pdf
>>>
>>> (in case you couldnt see my proposal as attached then this is the link)
>>>
>>> On Mon, Apr 20, 2026 at 1:00 PM Muneem <itfllow123_at_[hidden]> wrote:
>>>
>>> My proposal with conceptual implementation that you can run but the
>>> implementation does not have the exact implementation as one with
>>> std::variant<T&...> would have, like I could modify it but it would never
>>> be one to one, so see my implementation as a conceptual implementation
>>> roadmap meant to show how bookkeeping helps rather than showing the exact
>>> semantics of my implementation.
>>>
>>> I also fixed some Typos and grammar mistakes (in the code example
>>> section) that were in my updated docx file.
>>>
>>> On Mon, Apr 20, 2026 at 12:47 PM Muneem <itfllow123_at_[hidden]> wrote:
>>>
>>> Credits to this video:
>>> https://www.youtube.com/watch?v=LDPMpc-ENqY
>>> like in this video, at the end, he describes std::apply that was useful
>>> for folding tuples for me. I was lucky to see this a month ago while
>>> learning random number generators and reading Bjarne's great book. Without
>>> this video, My code couldn't be completed, like most of it is basic, except
>>> the part where I used std::apply because that was what took 3 hours to get
>>> a hint of, which is when this video came into mind somehow. Funny how the
>>> world is, like I programmed in my dream, literally solving this puzzle.
>>> This puzzle may look basic to the old timers but for me, this basic puzzle
>>> took like an honest 4 hours to prototype and 6 hours to fix
>>> completely(about 10 if you count the 2-4 hours in my dream).
>>>
>>> On Mon, Apr 20, 2026 at 12:25 PM Muneem <itfllow123_at_[hidden]> wrote:
>>>
>>> My code is complete:
>>>
>>> https://github.com/HjaldrKhilji/Future-potential-ISO-porposals/blob/main/Code_example.cpp
>>> https://godbolt.org/z/WWoWrd3q1
>>> My updated proposal is also attached and is also on the github link:
>>>
>>> https://github.com/HjaldrKhilji/Future-potential-ISO-porposals/blob/main/Runtime_Indexed_Tuples_Proposal_Official%20(1).docx
>>>
>>> Again, I am sorry for taking so much time on such trivial code. I know I
>>> should be faster, so hope it dosent reflect badly on the technical merit of
>>> my proposal
>>>
>>> On Sun, Apr 19, 2026 at 11:22 PM Muneem <itfllow123_at_[hidden]> wrote:
>>>
>>> https://godbolt.org/z/rs34q1Wj9
>>> This is what I got till today, I will debug this tomorrow, but yeah, I
>>> just wanted to show what's done till now before going to sleep.
>>>
>>> On Sun, Apr 19, 2026 at 8:54 PM Muneem <itfllow123_at_[hidden]> wrote:
>>>
>>> I am really really sorry that previously my code was not only using
>>> enable if but also the pattern of making types unique was wrong. I promise
>>> that I will fix it tomorrow and will test every possible specialization to
>>> make sure such mistakes don't occur again. Again, really really sorry. I am
>>> almost done with the proper code but it's just a little bit left that I
>>> left for tomorrow. I know it's nothing special and that I should be better
>>> at wiring such basic code but things happen and in my case, it would to not
>>> think properly so as to use recursion with conditinal_t.
>>>
>>> Regards, Muneem
>>>
>>> On Sun, 19 Apr 2026, 8:28 pm Thiago Macieira via Std-Proposals, <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>> On Sunday, 19 April 2026 01:01:13 Pacific Daylight Time Muneem via Std-
>>> Proposals wrote:
>>> > This is the example implementation code:
>>>
>>> Send the link to the working implementation in godbolt or your
>>> repository on
>>> GitHub/GitLab/equivalent.
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>>> --
>>> 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
>>>
>>> --
>>> 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
>>>
>>> --
>>> 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
>>
>