I would not say it to be ingenious or pretty, the three solutions I altogether brought up are the ones most people here on this list are thinking about as possible solutions. There are not so many ways to do it.   Some standard library types are high level, some are basic building blocks. The basic building blocks have to be minimalistic and should be quite fixed, how an implementation would implement them. That is important that power users or library programmers (normal libraries, not the standard libarary) can rely on certain performance (memory, runtime) properties.   Sometimes those properties are observable, sometimes not. E.g. the storage in vector is contiguous. Or ownership semantics or typical size of the type like std::array not having any overhead.     In your use case, the container (tuple or array) should be a standard building block.   The variant may be something else. You said you don't like std::visit. And there are better possibilities with interface-like constructs between non-related types. But your proposal does not go into that direction.   And just for taking out a runtime indexed element out of a std::tuple, we are in basic building block territory.     If you want that the type cannot be changed afterwards - as somebody on this list alredy pointed out -, write       const std::variant<int*, double*, std::string*> v = get_index(t, idx);           or       const auto = get_index(t, idx);     The const here prevents the variant to point to a different type than the initial one.     The aim of all C++ proposals should be to be minimalistic, to make as few changes as possible,  - to make the language stable  - to not have too many solutions for each problem - C++ was created by Bjourne Stroustrup, not by Larry Tim Toady Wall :-) (TIMTOWTDI)  - to keep the workload off the committees (and implementers)  - to keep the features orthogonal - one should be able to combine them well; too many classes doing the same would lead to e.g. std::tuple having to return 15 different variant types     If you want to extend the C++ language in a more substantive manner, you have to prove that there is a huge potential. Just saying the implementors should have freedom, there can be book-keeping, is not enough. You have to be concrete and prove it. Otherwise your proposal still can be minimal and just add a member function to std::tuple or allow std::variant to work with references.   That are evolutionary and good improvements, nothing revolutionary. But we don't see, what you bring to the table, that is revolutionary. I (and others like Simon) came up with possible implementations. Instead of going into detail, which of those and how it would give performance improvements, you go back to the implementation can choose or some trivial usage issues. If you have no more concrete idea how it can be more performant, then we have to assume it cannot be more performant. That's okay, but then let's not waste time to discuss it in circles. We all hoped there was something to the idea, but so far we see some small improvements to the status quo, but not a big one. And a big one is not introducing JIT (this is a method to achieve something), but to say what can be optimized.   C++ from the very start could be reduced in identical C expressions. Including polymorphic inheritance. Not the syntax of the language and the checks, but the low-level parts, C has pointers to manual vtables and from there function pointers, and enums for type specifiers. So all the performance of C++ normally can be expressed in C terms, in concrete object layouts. Come up with a performant object layout. Build it with the existing building blocks. Show that it is so fast, that it should be the standard way, but that combining the building blocks is cumbersome. Than dedicated classes could be proposed for it (or extensions to existing classes), making it safer and easier to use.   -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 18.04.2026 12:57 Betreff:Re: [std-proposals] Extension to std::tuples to allow runtime indexing. An:std-proposals_at_[hidden]; CC:Muneem <itfllow123_at_[hidden]>; While your solution was ingenious and pretty clever, there are a few issues that can't be addressed well without standard library support: 1. The issue with the get_index function is that it returns a variant of pointers, and you can change the type variant currently holds, which is something that you should not be able to do since, hence leading to my proposal of a variant<T&...> , which since no existing ABI's depend on it, can have its own thing(ABI) specifically tuned for this purpose. 2. Your proposal dosent allow implementations to store book keeping information in a tuple, which leads to less "mechanical optimization". The reason current tuples aren't runtime indexed is because they aren't built for that.  All this is to say that even though your solutions are ingenious and innovative, they are trying to make as less additions as possible, which is a issue because standard library isn't meant to be minimalistic but rather a library of generic "vocabulary types".