1. What I meant by the freedom to optimize was the freedom to have whatever
mechanics that suits runtime indexing to be used to implement that
particular specialization of the tuple, I used the term optimization losely
for which I am really sorry, but the point is very similar to how vectors
can optimize traditional arrays by providing move semantics.
2. The issue with a union of pointers is the possibility of null pointers,
which means that you will have to do at least one check during conversation
or many checks on every access, both of which are highly undesirable and
the latter will mutate the meaning of pointers by not allowing it to be
null. This is why it is better to have newer mechanisms that are to be
implemented by every implementation. In the case of reference wrappers,
they are just wrappers around references, that's all they really are.
3. It is inappropriate because references are really just references to
objects, and in this way they differ from pointers because they are an
alias rather than a flexible arrow that you can point around like in the
case of pointers.
4. The interface is the same in my case as well, the only difference is the
inclusion of a new subscript operator, and an implementation defined book
keeping data to optimize random access at runtime.
5. Unions cant have references and variants are a form of unions that we
see as a "tagged union", which means that we dont know what the rules
should be, but it sounds very logical and intuitive to say that if a
reference is once assigned to, than it becomes an alias, hence a union of
references should be an alias to an object.

note on the file attachment:
I changed my name to my original name in my main formal (I had previously
added a title(Noorzada) that is something that Pashtuns do), but I find
that really unprofessional in hindsight and am really really really sorry.
It's just a bad habit for some of us to use fancy Persian/nordic/any made
up titles. Hope you guys forget this mistake. I promise to confine such
unprofessional mistakes while trying to act slightly edgy to my personal
life.

On Fri, Apr 17, 2026 at 5:49 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Apr 17, 2026 at 12:42 AM Muneem via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > 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.
>
> Nothing you've said here addresses the question. What you've given is
> a series of general statements; some of them are true, some of them
> are non-sequiturs, and some of them aren't true. But the overall
> effect is that your argument is based on theory, not practice.
>
> In particular, the lynchpin of your argument is the belief that "the
> optimizer needs complete freedom". This is false. It doesn't need
> "complete freedom"; it only needs "enough freedom" to optimize the
> code for a particular case. What you need to show is why having to use
> the tuple's ABI is not "enough freedom" to optimize runtime indexing.
>
> Basically, you take it as an article of faith that having to use the
> tuple's ABI *must* be slower than a different ABI. Why would that ever
> be the case? Why would the order of items in a tuple affect runtime
> indexing performance?
>
> > > This also means common implementations of variants (tagged unions or
> "closed set unions") might not suffice. Instead, implementations should use
> techniques similar to typeid or other internal mechanisms.
> > You can't have a union of references, but however, as I said, you can
> have reference wrappers which are like pointers.
>
> That's functionally equivalent to a union of pointers. It wouldn't be
> difficult at all for a variant to simply implement the type it stores
> in its internal union as a pointer if that type is a reference.
>
> > >The main reason for this variant specialization to exist is that it
> cannot be valueless.
> > Variants of references dont exist, so adding allowing references to
> exist in variants requires a new set of rules.
>
> I asked why it needed *those rules*. Why is it inappropriate for a
> variant of references to be valueless? Why is it inappropriate for a
> variant of references to be unable to change which item is active?
>
> > Basically, a variant of const T will act differently than T, Based on
> the behaviour of the const type modifier. SImilarly variants of references
> should act differently based on how references already act.
>
> That's not a specialization that changes the interface. The interface
> is the same; what changes is how you get to manipulate the type in
> question. `T const` is not the same type as `T`, so you shouldn't
> expect things that work on a `T` to necessarily work on a `T const`.
>
> Becoming valueless or being unable to change which is active has
> nothing to do with the variant conceptually having references.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>