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.