Date: Fri, 10 Apr 2026 14:05:50 +0200
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] <mailto: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] <mailto: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
Received on 2026-04-10 12:07:10
