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
>