Also the issue really just is the fact that you have to rewrite the
indexing operations again and again. Which isn't always efficient, for
example, I might think storing a array of std::variant<T&...> Where every
element is initialized to the respective T In The t... Passed to the tuple
as templates arguments, but this example may backfire depending on the
specific implementation. Another person might ask why implement std variant
with pointers and store pointers for every T, then intialize the variant
using the respective pointer. All this boils down to the fact that there
could be a million wheels but all of them depend on the terrain that you
drive them on, hence the better way is to leave it to the
experts(implementation) while having a standard interface of using them
your example may be better or maybe worse, like it all depends on the
implementation.

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

> Which "own new mechanics"? Which has an influence on object layout?
>
>
>
> The current std::tuple can do runtime indexing. Even if it has no suitable
> member function, as std::tuple is a value type (everything stored is freely
> accessible without overhead and the object layout is known), one can just
> program a free function for runtime indexing.
>
>
>
> Other example of a layout with book-keeping:
>
>
>
>
>
> *std::extended_tuple_2*
>
>
>
> void* lastused;
>
> int lastindex = -1;
>
>
>
> double d;
>
> int i;
>
> float f;
>
>
>
>
>
> Here you cache a pointer to the last used member. This would probably
> still be worse than the standard std::tuple in every metric, even if you
> always access with the same index.
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Fr 17.04.2026 10:26
> *Betreff:* Re: [std-proposals] Extension to std::tuples to allow runtime
> indexing.
> *An:* std-proposals_at_[hidden];
> *CC:* Muneem <itfllow123_at_[hidden]>;
> 1.Existing API are unchanged except for the addition of the subscript
> operator in tuples. To make this possible, conversions from the new tuple
> to normal tuples is possible. SImilarly, conversions from
> std::variant<T&...> to std::variant<T...> is also possible.
> 2. The code for each specialization of a tuple can be unique but the
> compiler needs to know for sure which tuple should be optimized
> specifically for runtime indexing and which is not to be. My proposal is to
> make that very clear for the compiler. By optimizing it for all tuples, I
> am practically making existing code that relies on existing tuples
> incompatible. Basically, the ABI of every specialization is expected to be
> the current tuple implementation, but my proposal is to make a new line of
> specializations that no code relies on, that has its own new mechanics
> specifically tuned for runtime subscripting of that tuple. The same goes to
> std::variant<T&...> and std::optional<T&>.
> 3.I am sorry for the formatting issues in my email, like really really
> sorry.
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>