My response to Mr.Jason is that the standard requires that a variant that
be have its underlying type changed, while in my case, I don't. This is
important since again, you can merge branches more efficiently if that
gurrenties is provided, since if one branch for a using a tuple element at
runtime leads to the type turning out to be int^ at runtime, the compiler
can merge the branches required for that int^ at runtime. Variant can't do
that because it requires the that the type can change, while in my case,
once an element at a specific index of the heterogeneous list is chosen,
the type CANT change, which means that you can avoid branching again and
again without thinking twice.

On Fri, 10 Apr 2026, 7:17 pm Jason McKesson via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Fri, Apr 10, 2026 at 8:41 AM Muneem via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Let me rephrase: By definition, the optimizer cannot nullify the
> semantic meanings set by the Sema (Semantic Analyzer) component of a
> compiler. Sema depends on the context defined by language level constructs.
> ABI boundaries are a consequence of this fundamental detail of compiler
> theory; therefore, to add features that are mechanically fast, you need new
> syntactic constructs that dictate how Sema interprets their semantic
> meaning.Optimizers cannot change the fundamental meaning of your code; only
> new constructs can. Strict dynamic typing has a fundamentally different
> meaning than closed set duck typing. Hence, the optimizer cannot and should
> not take that semantic meaning away in a bid to optimize any implementation
> of strict dynamic typing in terms of closed-set duck typing or else, as I
> explained, ABIs will break.
>
> If the only justification you have for what you want is the "logic"
> that semantic meaning make things fast, I want this new thing to be
> fast, therefore for my new thing to be fast it must add semantic
> meaning to the language... that's just wrong.
>
> You cannot point to an actual thing inside `variant` that would make
> it slower than your theorized construct. You can only wildly
> gesticulate with theoretical arguments.
>
> Consider your `flat_map` allegory, `flat_map` needed to exist as a
> separate type from `map` because specific standard-required behavior
> defined for `map` prevents an implementation from doing what
> `flat_map` does internally. Iterators and references to an element in
> a `map` are required to only be invalidated if you remove the specific
> elements those iterators/references refer to. The restriction prevents
> using a sorted array, since removing elements to one side of the
> referenced items will change their address. As such, a `map`
> implementation is forbidden from using a sorted array, so it cannot
> achieve the speed of `flat_map`.
>
> This is not a theoretical argument that you need new semantic meanings
> to make things fast. This is a specific argument based on the actual
> facts of the specific types in question. I pointed at behavior that
> the standard requires of `map` and showed that the implementation
> `flat_map` uses would violate that required behavior.
>
> You cannot point to a similar case with `variant` and your
> hypothesized "closed set duck typing" type. If I'm wrong, please point
> to the *specific behavior* the standard requires of `variant` and show
> precisely how the performance of the type you desire cannot be
> achieved in light of that required behavior.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>