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.

On Fri, Apr 10, 2026 at 5:37 PM Muneem <itfllow123_at_[hidden]> wrote:

> By definition, The optimizer can't nullify the semantic meanings set by
> the Sema/Semantical_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, so to add
> features that are mechanically fast, you need new syntactic constructs
> where the way Sema interprets their Semantic meaning. Optimizers can't
> 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 cant and should not take that semantic meaning
> away in a bit to optimize any implementation of strict dynamic typing in
> terms of closed set duck typing, or else as I explained, ABI's will break.
>
> On Fri, Apr 10, 2026 at 5:29 PM Muneem <itfllow123_at_[hidden]> wrote:
>
>> std variant is still a union, like it has the baggage of a union. The
>> "type safety" that is probably achieved by a few underlying tags is just to
>> help you keep track of what the union means. It is not type safe in its
>> mechanics but used to wrap something meant to be flexible. You are right
>> variants are closed sets, sorry, but it is still based of a very flexible
>> closed set (a union). Like why implement strict dynamic typing in the
>> mechanical terms of closed set duck typing!?
>>
>> On Fri, Apr 10, 2026 at 5:07 PM Sebastian Wittmeier via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> The difference between std::variant and union is that std::variant is
>>> type-safe.
>>>
>>>
>>>
>>> std::variant stores, which type out of a closed set is active.
>>>
>>>
>>>
>>> For an open set one would e.g. use std::any instead.
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
>>> *Gesendet:* Fr 10.04.2026 13:34
>>> *Betreff:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>>> proposed
>>> *An:* std-proposals_at_[hidden];
>>> *CC:* Muneem <itfllow123_at_[hidden]>;
>>> Why do we need to go in circles? Like std::variant is a union hence not
>>> STRICTLY DYNAMICALLY TYPED. It's like you would use an array of variants or
>>> rather use a tuple of the same types, the answer is the former if the goal
>>> is complete duck typing over a closed set, and the latter if you want fixed
>>> types at fixed indexes. Both work well for their job. Similarly you need
>>> new types for strict dynamic typing. All three concepts are their own
>>> domains: strict dynamic typing(my proposal), open set duck typing(variant),
>>> and strict static typing(tuples).
>>>
>>> On Fri, Apr 10, 2026 at 4:28 PM Bjorn Reese via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>> On 4/9/26 20:11, Muneem via Std-Proposals wrote:
>>> > My answer to Mr.Bjorn: I didn't say that you did have book keeping,
>>> > infact that's the issue, like to copy a tuple elements in a variant
>>> and
>>> > to make sure that you can't change the type of that variant to
>>> anything
>>> > afterwards, you do need book keeping Information. Without a language
>>> > level construct, you can't optimize such Information without breaking
>>> > ABI's, just like how we needed flat maps, we need a language level
>>> > construct.
>>>
>>> std::variant already contains this bookkeeping, so no ABI changes are
>>> needed.
>>>
>>> Furthermore, the tuple visitor solution does not need such bookkeeping
>>> at all.
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>