1. That was just a possible optimization and I wasn't storing variants in
variants, but rather a variant<enable_if_t<Is_t_in_set<T, T...>(), T&>...>(
https://en.cppreference.com/w/cpp/types/enable_if.html while Is_t_in_set
t is defined in my txt file) in an array initialized to every object of
type T in the T... passed to the tuple. The point is that the goal was to
have a new API that dosent have any ABI depending on it and can be used
with existing APIs thanks to explicit conversions(through constructors) to
normal tuples, variants, and optional objects, while allowing these
optimizations that the implementation might expect to be fruitful in
solidifying the optimization of the code. This again, can be done with
existing tuples that have an extra subscript operator because they have
ABIs depending on certain specializations of them that expect a certain
layout.
2. All your solutions show that smart users have multiple choices on how to
reinvent the wheel, but none of them are optimal for most cases and are
constrained by existing ABI's. What we need is a standard interface that
locks and gives the user a straight path on exactly what to do.

On Fri, Apr 17, 2026 at 4:18 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> [You would need T* const instead, asterisk before the const]
>
>
>
> Your new class can only be optimized once, afterwards it is also
> ABI-locked. So all optimizations we cannot spell out now, probably will
> never materialize.
>
>
>
> In your use case storing the variants in tuple is not necessary, if you
> have variants to references. It is an anti-pattern to have views to views.
> (or references)
>
>
>
> Either
>
> Store the actual objects in a tuple (tuple of T1, T2, not T1*, T2*) and
> create a variant to a reference of it on the fly (my previous 2nd solution)
>
> Or store an array of variants of references and copy the selected variant
> out of it with each use (cheap copy) (my previous 1st solution)
>
> Or Store in a tuple to T and generate on-the-fly a view class to the
> tuple, which stores the selected index. (similar to my Dispatch class)
>
>
>
> That are the three principal solutions.
>
> Some of those need a bit of help (by the standard consortium) like
> enabling variants of references or additional accessors.
>
>
>
> I don't think there will be a solution, where the implementation can do it
> in any of those ways.
>
>
>
> And as we already have existing facilities like array, tuple, variant,
> those will be extended,if possible.
>
>
>
> Much more interesting is a variant, which offers the combined interface of
> all or at least several of its possible element types.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Fr 17.04.2026 12:01
> *Betreff:* Re: [std-proposals] Extension to std::tuples to allow runtime
> indexing.
> *An:* std-proposals_at_[hidden];
> *CC:* Muneem <itfllow123_at_[hidden]>;
> 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
>
> --
> 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
>