Let me rephrase for more clarity (sorry for my grammar( I feel sleepy and
its burning hot)):
Why do we need to go in circles? std::variant is a union; therefore, it is
not STRICTLY DYNAMICALLY TYPED.
It’s like this: you would use an array of variants (or a tuple of the same
types) depending on the goal. Use the former if the goal is open-set duck
typing over a closed set, and use the latter if you want fixed types at
fixed indexes. Both work well for their specific jobs.
Similarly, you need new types for strict dynamic typing. All three concepts
are their own distinct domains:
Strict dynamic typing (my proposal)
Open-set duck typing (variant)
Strict static typing (tuples)

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

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