In most cases we want the both and it is a good idea to leave the standard
to choose between book keeping or not because indexing a heterogeneous list
like a tuple is a fundamental notion which like strings should be
standardized instead of asking the user to make it himself.
The issue is really that we want to own (mantain traditional invariant of a
tuple) and keep book keeping (to optimize the subscript) operator. Your
solutions provide the solution for a single problem, instead of both. Any
new solutions would basically reinvent the notion of a tuple, while this
specialization uses the notion of a tuple and expands it by adding extra
implementation defined book keeping as I explained before.

On Fri, 17 Apr 2026, 5:14 pm Sebastian Wittmeier via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

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