Please clearly differentiate between ABI and API. For API the provided functions and their semantics are relevant. For ABI the underlying storage, the standard member functions and how it is passed as paarameter.   If the compiler gets information at compile-time and stores that information in the type "name", i.e. templated types, then it counts as separate type and the ABI can be adapted for it. Otherwise (at least over ABI boundaries) the compiler has to work with the storage and information it has about the project.   In your case, some of your defined objects are identical in ABI (not necessarily API) with std::tuple and only have small differences (possible reference elements, no change later of the type) to std::variant. The basic storage of the objects is identical. Which also means that a compiler would probably generate identical code.   PS Please at least insert a single empty new line before your answers. Sometimes (especially with inserted > at the start of lines, the line endings before get ragged. And some referenced lines won't start with >. It is very difficult to see your answers out of the text).     -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 17.04.2026 06:43 Betreff:Re: [std-proposals] Extension to std::tuples to allow runtime indexing. An:std-proposals_at_[hidden]; CC:Muneem <itfllow123_at_[hidden]>; Thanks for your feedback: > Existing tuples cannot be optimized for runtime indexing without breaking ABI (Application Binary Interface). >You responded with: Where's the evidence for it? The evidence is that without *STANDARD* support for runtime indexing, programmers will reinvent the wheel that might not always be efficient. To optimize such a wheel, the optimizer needs complete freedom, which it does not have because it has to maintain ABI compatibility for the components of the wheel. Again, standard library defeats the user in optimizing say a container, since the container can be built with inline assembly if the implementor thinks that is efficient for that implementation, where as user written code is built on multiple blocks, where each has its own implied invariant that contributes to the semantic meaning of that block, hence it cant be optimized away by the compiler. Since, According to basic compiler theory, the optimizer can only optimize such that the semantic meaning of the code dosent change.