The issue with the first(array of std::variant<T&... or T*... or T const*> ) is that it is not guaranteed to be fast(Again, the implementation knows better) and it also dosent support tuples storing the objects, which again, leads to less control over the life times of the objects, which isnt always type safe since the T& in the array may refer to a T object that does not exist.

The issue with modifying existing tuples is that current ABIs designed for certain tuple specializations will expect the tuple to be like existing tuples, and by include subscript operator in existing tuples would mean that the tuple cant be optimized without breaking existing code and/or the zero overhead principle. The possible optimizations are as I discussed bookkeeping information like storing an array of variants or anything the implementation sees fit.

On Fri, Apr 17, 2026 at 2:52 PM Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

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@lists.isocpp.org>
Gesendet: Fr 17.04.2026 11:42
Betreff: Re: [std-proposals] Extension to std::tuples to allow runtime indexing.
An: std-proposals@lists.isocpp.org;
CC: Muneem <itfllow123@gmail.com>;

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@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