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.