I feel like you misunderstand the complexities of (strict) dynamic typing,
like seriously, strict dynamic typing is not duck typing(variants) or
metaprogramming(templates and reflectors). We keep on going in circles
without realizing that what I am proposing so a strict dynamically typed
systemed built separately. C++ philosophy is quite the opposite of building
everything into the library. Like compare the language features of c++ to
any other language. C++ language features always grew and should grow or
else others will take over. Dynamic typing is something that every
programmer has to deal with and no everyone can make a "arethimetic engine"
in 2 months and spend another 3 debugging and optimizing it(by measuring
and figuring out) . People need a language level construct for domains that
are completely new, and dynamic typing is a completely new domain.

On Fri, 10 Apr 2026, 10:38 am Simon Schröder, <dr.simon.schroeder_at_[hidden]>
wrote:

>
>
> > On Apr 10, 2026, at 5:03 AM, Muneem via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > It dosent have to cook with water, like it's a new feature.
> “Cooking with water” is a metaphor for that your proposal still needs to
> use the same compiler, the same optimization techniques, and the same
> hardware. As long as the hardware doesn’t change both your new type and all
> existing types have the same CPU instructions available. And honestly, the
> easier the code you write the easier it is for the compiler to optimize.
> More different optimization strategies will not fit into the time budget
> that compiler writers put into compilers.
>
>
> > And the library can't achieve the same thing without breaking existing
> code, like how are you gonna let the compiler optimizes a variant for std
> visit without expecting code expecting a normal variant to not work.
> I still fail to see any optimizations you are proposing that would not
> work for existing uses of std::variant. Wouldn’t all uses of std::variant
> benefit from the optimizations that you propose? Your new type is in
> general terms still a union/variant/tagged enum. In theory, it can be used
> in all places a std::variant can be used. How do you teach when to use
> what? If in the end your new type would effectively replace std::variant,
> we really should be changing std::variant (at least it is a good name and
> it’s better to reuse it than to invent a new awkward name). Yes, we hate
> breaking ABI. But, it has happened with std::string on GCC before (and MSVC
> used to constantly break ABI with every new version). ABI changes usually
> don’t break code, but only linking with existing libraries. If there is a
> good reason (and if it happens rarely) we should break ABIs.
>
> > The solution is a new construct. Like how can you say that the gain is
> non existent. It's like I can write something similiar to template
> metaprogramming patterns using macros but should I? Will that be better?
> The standard prefers library solutions over new constructs. If with minor
> changes to the language we can make your proposal work as a library, this
> is the preferred route. Built-in types should not have any special
> privileges in C++. A user-defined type should have all the privileges of a
> built-in type (this is why we have operator overloading). If we adhere to
> this principle, your new type should be implementable as a library type. If
> you don’t like this philosophy of C++, choose a different language.