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
>>
>