Two solutions have a tuple owning the objects, the other has references even in the container.   One (Dispatch) is using bookkeeping, the other is just a variant.   So only the two owning solutions could be made API compatible.   I think it is not good to allow the implementers to choose  between bookkeeping or not. Better to have clear building blocks.   -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 17.04.2026 13:43 Betreff:Re: [std-proposals] Extension to std::tuples to allow runtime indexing. An:std-proposals_at_[hidden]; CC:Muneem <itfllow123_at_[hidden]>; 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] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> ; CC:Muneem <itfllow123_at_[hidden] <mailto: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] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> ; CC:Muneem <itfllow123_at_[hidden] <mailto: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] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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