You want a simple way:   That is possible today.    https://onlinegdb.com/Het7pmsSr   -> a std::tuple -> retrieving a variant by a runtime index -> passing it to a function   One could improve by standardizing get_index   -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 18.04.2026 06:34 Betreff:Re: [std-proposals] Extension to std::tuples to allow runtime indexing. An:std-proposals_at_[hidden]; CC:Muneem <itfllow123_at_[hidden]>; 1. Sorry that my first two answers weren't clear enough: in the first answer, the tag was for partial specialization and the in the second what I meant by tag was book keeping information. 2. I get that by allowing book keeping information, my type isn't trivially copyable anymore, I am sorry that I didn't think about it properly, it didn't seem significant at of me answering. I also want emphasize that normally users want a specific runtime tuples, they don't want to think about ways to implement it or weather's it's trivially copyable or not because they really just don't care. If this proposal gets passed then with variants of T&... ,You could implement other kinds of tuples but normally you would not want to do that, normally you would want a simple way to define and use runtime indexed tuples. My proposal provides a standard interface for that. On Sat, 18 Apr 2026, 8:42 am Jason McKesson via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On Fri, Apr 17, 2026 at 10:27 PM Muneem via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: > > 1. My proposal uses a tag in std namespace and since std namespace is reserved, no one would be using it anyway(by defining their own tags). That changes nothing about what I said. None of my examples use specific typenames; they're all based on template deduction, which is done now. Look at implementations of `std::apply` and explain how it would work with a tagged tuple without changing its implementation. > 2.i didn't meant a tag for current tuples because that's really not useful, since current tuples get their element from recursion,which though inefficient is efficient since it's at compile time. You will however need tags or other book keeping information at some point if you were to avoid such potentially inefficient recursive/looping patterns. >From the first sentence of your proposal: > This proposal provides a specialization of std::tuple that can be indexed at runtime. You're asking to make a specialization of `std::tuple`, which is triggered by the use of a tag type. > 3. Copying a my tuple would also be trivially copyable and explicit conversion to normal tuples. That's not possible. Remember how I brought up copy-on-write `std::string` implementations? That kind of implementation was made possible in C++98 by very particular wording around pointer/reference/iterator invalidation. C++11 shut down CoW strings by taking that particular wording away. I bring this up because a trivially copyable type cannot have pointers to itself. Well, they cannot *maintain* those pointers being pointers to themselves across a copy. If you have a type like this: ``` struct foo {   int i = 30;   int *pi = &i; }; ``` Value initialization for this object will leave it in a state where `pi` points to the `i` member of the object. But if you copy this object, the new copy's `pi` will not point to its own `i` member; it will point to the copied-from object's `i` member. Same goes for movement. In order to guarantee that the copied `pi` is a pointer to the internal object's `i` member and not someone elses, you need a copy constructor (and move constructor): ``` struct foo2 {   foo2(foo2 const& other) : i{other.i}, pi{&i} {}   int i = 30;   int *pi = &i; }; ``` `foo2` is not trivially copyable. If `runtime_tuple` is trivially copyable, that will forbid the implementation from being able to maintain pointers to its members across copy/move operations. That is, if you want bookkeeping information to point to its members, it *cannot* be trivially copyable. It's one thing or the other. You cannot have both. -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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