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@lists.isocpp.org>
Gesendet: Mo 20.04.2026 11:01
Betreff: Re: [std-proposals] Extension to std::tuples to allow runtime indexing.
An: std-proposals@lists.isocpp.org;
CC: Muneem <itfllow123@gmail.com>;
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@lists.isocpp.org> 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@lists.isocpp.org>
Gesendet: Mo 20.04.2026 10:03
Betreff: Re: [std-proposals] Extension to std::tuples to allow runtime indexing.
An: std-proposals@lists.isocpp.org;
CC: Muneem <itfllow123@gmail.com>;
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@gmail.com> 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@gmail.com> 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@gmail.com> wrote:My code is complete:
https://github.com/HjaldrKhilji/Future-potential-ISO-porposals/blob/main/Code_example.cppMy 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 proposalOn Sun, Apr 19, 2026 at 11:22 PM Muneem <itfllow123@gmail.com> 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@gmail.com> 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, MuneemOn Sun, 19 Apr 2026, 8:28 pm Thiago Macieira via Std-Proposals, <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-- Std-Proposals mailing list Std-Proposals@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-- Std-Proposals mailing list Std-Proposals@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals