My response my Mr.Thiago Let's forget the bench marks for a second, and
focus on the larger image of the limitations that I faced In implementing a
dynamic type system. Micro dispatches may not matter on a small scale but
it's like if if statements get slower then the effect is small in small
projects and large in large ones. Similiarly if you were to access variants
again and again and again, then you have the effect of the 13500% slower
speed increased. Again, dynamic typing is not a esoteric branch of
programming, infact as people move towards building large infrusture to
connect AI tools to automated scripts and to help them operate those tools,
we need real time systems, and real time systems often require flexibility
as they become complex. In the case of my virtual machine, it was meant to
be a simple way to build compilers but ended up having a whole large file
for dynamic typing. I would argue that the reason Python is used to deal
with large systems operated by AI or some other system is precisely because
it supports dynamic typing(cuz it's interpreted). In the case of python,
it's slow and the way it does dynamic typing is rather not strict
enough(duck typing behaviours) that though could be mitigated with newer
type constrained features are still causing issues in existing python code
bases. C++ on the other hands can support dynamic typing in way that allows
for strict closed set dynamic typing only. If that happens then people
would have no reason to use python over C++ in the majority of cases,
except the ones where you just want to automate a small task.

On Fri, 10 Apr 2026, 8:02 pm Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Friday, 10 April 2026 04:34:24 Pacific Daylight Time Muneem via Std-
> Proposals wrote:
> > Why do we need to go in circles? Like std::variant is a union hence not
> > STRICTLY DYNAMICALLY TYPED.
>
> No, it isn't. That depends on the code you write. You can very well
> operate
> only on the type it currently has, without changing.
>
> For the purpose you've espoused -- using one of many possible list
> implementations -- std::variant *works* *just* *fine*.
>
> From the analyses of the assembly generated by the compiler in the
> benchmarks
> you posted about a week ago, the difference is only where the "current
> type" is
> kept. With std::variant, since it is kept inside of the variant, the code
> emitted by the compiler ends up checking it every time. Quite likely, if
> you
> had two visitors back-to-back, the compiler would fail to realise it's the
> same current type and do two dispatches. That's a QoI problem and can be
> fixed
> in the compiler.
>
> With your external type selection, the compiler has an easier time proving
> the
> choice did not change and thus optimise the code to make a single dispatch
> to
> multiple visitors.
>
> That doesn't mean we need a new type. In real-world scenarios, the cost of
> extra dispatches is likely negligible -- as it was in the
> micro-benchmarks.
> There may be some edge cases where it is meaningful, but that does not
> imply
> the solution needs to be in the Standard Library. There are many
> specialised
> algorithms and containers that aren't due to their limited usefulness to
> the
> general public. Moreover, there is a cost in *adding* them: maintenance by
> the
> implementations, teachability, readability, etc.
>
> And more importantly, NONE of this implies we need a language change. That
> should be an orthogonal discussion.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>