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.

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

> 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.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>