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
>