Date: Fri, 10 Apr 2026 08:01:56 -0700
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.
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.
Received on 2026-04-10 15:02:08
