Date: Fri, 17 Apr 2026 08:49:26 -0400
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_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.
Received on 2026-04-17 12:49:40