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_at_[hidden]> 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_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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>