So from a low-level perspective you basically would create an array of pointers (references are typically implemented as pointers) and everything a bit more type-safe.   Yes, could make sense to standardize.     But the two alternatives are also looking good:   1) Standardize std::variant<&T1, &T2, ...> und use a std::array of std::variant. Less type-safe. But nice enough.   2) Change std::tuple to return a std::variant<&T1, &T2, ...>. by runtime index. The std::variant is not inside the type, but is created on the fly. If you have a single pointer and a type specifier inside your std::variant, it is small enough to be created on-the-fly and passed in registers to other functions.     I think I like 2) best.   -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 17.04.2026 11:42 Betreff:Re: [std-proposals] Extension to std::tuples to allow runtime indexing. An:std-proposals_at_[hidden]; CC:Muneem <itfllow123_at_[hidden]>; 1.I dont want that optimization but if the implementation sees it as fit then it would.  2.  The reason for the std::variant<T&...> to be proposed is to avoid the exact space overhead that you are talking about.  3.std::array<std::variant<double, int, float>, 3> isn't guaranteed to be fast, similarly it might encourage people to make many variants of this implementation, which again is ad hoc and messy. What needs to exist is a standard interface that the implementation can implement in whatever way it sees fit, so that the runtime tuple is fast and people dont reinvent the wheel. In fact, in your case, you also had a temptation to reconsider: std::fixed_variant_array<double, int, float>, which again means that on large scale, many people will implement many of these, leading to a mess like openssl's C api implementation where everything openssl made and little to nothing is borrowed from the C standard library, which in my case, made me be scared of cryptography and networking libraries for a whole year. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals