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
>