Date: Sun, 5 Apr 2026 06:35:24 +0500
---------- Forwarded message ---------
From: Muneem <itfllow123_at_[hidden]>
Date: Sun, 5 Apr 2026, 6:25 am
Subject: Re: [std-proposals] Fwd: Extension to runtime polymorphism proposed
To: <std-proposals_at_[hidden]>
Hi!
Thank you so so much for your feedbacks ❤️❤️❤️.
I woke up after a 6 hour nap (I couldn't sleep anymore). I will first give
a short response to expand on the problem, then my solution, before
response to every welcomed feedback:
Problem:
So imagine a base class (as Steve shows):
class Storage
{
public:
class Data {// TBD };
class Key {// TBD};
inline void put (const Key &, const Data &) {
storage[discriminator(data)].put(data);}
Data get (const Key &) const { return
storage[discriminator(data)].get(data);}
private:
int discriminator (const Data &) { // do something}
class Impl
{
public:
virtual void put (const Key &, const Data &) = 0;
virtual Data get (const Key &) const = 0;
};
class FlavorOne : public Impl
{
private:
void put (const Key &, const Data &) override {// do something}
Data get (const Key &) const override {//do something}
std::vector<Data> data;
};
FlavorOne flavorOne;
********Problem with this********
1.You can't instantiate templates of the right derieve class using class
base class reference/pointers. Why? Because virtual functions can't be
templates. This is a sore thumb that was the last straw for my virtual
machine code.
2.You can't move a derived class object.
3.it is verbose because:
1. templates don't work
2.moves don't work (hence gonna have to do optimizatioms myself)
3 every operator that you want to use polymorphically has to be a member
function.
4.The abstract tree doesn't provide intent, it just shows and interface
that is implemented by multiple classes, which is like expecting compilers
to move data from lvalue references instead of simply using rvalue
references.
5.types of each override member function has to strictly match, like unlike
compile time template instantion where every type argument provides
fullfills a specific concept/requirement, this requires the exact interface
for each overriden function.
6. You can't provide function overloads that take a pointer and know it's a
polymorphic interface to any object, which again not only hides intent but
doesn't allow you to overload based on polymorphic objects, in to provide a
whole class of optimizations that apply to polymorphic objects or at least
to provide optimizations like std move that already exist.
********Problem with this********
********Solution********
1.provide a new construct that:
{1, std::string{}, obj2} select_name(1);
1. The select_name itself can or cannot(based on what you guys see fit) be
a new expression type.
2. The values inside HAVE(for the advantages to work) a new expression type.
****The advantages of the second point:****
1. Can be passed to templates to instantiate a template where just like
normal types, it can be passed to the templates that are called by that
template.
2.You can use move operations.
3.Is not verbose because it doesn't have the same issues
abstract/polymorphic class Hirearchies do.
4. Provides intent on a abstract tree level because it's a new expression
type which can (just like how rvalues gurrentied(copy elision) and provide
optimizations(move semantics)) can also with time have optimizations
provided to it by both gurrentied and new optimization semantics (similiar
to how functions(especially constructors) can be overloaded to take rvalue
references to optimize code).
5. No type needs to match, just like templates, all members functions used
must be provided by each type, and each type should be able to be passed to
any function that an object at any index can be passed to
6. Specific function overloads can be provided to provide a class of
optimizations and make the code scream the intent that here an
heterogeneous set element is passed, so what can we do to make it optimal.
********Solution********
Questions to ponder on:
1.why were rvalues introduced when you or the compiler backend can do it
thenselves?
2. Why were spaceship operators introduced when you can do it yourself?
3. Why do any new language construct in any human language exist? (Hint:
the more constructs in a language, the more you can change your writing to
target with any particular group that you want to target. For programmers
it's the same if constructs are represented on an abstract tree level)
4. C++ Is really good at metaprogramming, but not for polymorphic objects,
so isn't that an issue?hint: if only this is fixed then imagine everyone
writing Metaprograms only, like I love metaprogramming because of how fast
it feels, faster than writing python.
****Answers to all (defense in long form)*****
Mr. Simon asked:
>I feel like you are misunderstanding how compilers work (I am also not a
professional in this field). From my understanding modern compilers don’t
do much optimization of the AST (though this is different for JIT
compilers). LLVM has several different frontends for different languages,
but the backend is the same. In a first step the programming language is
translated to IR (intermediate representation). This is much like an
architecture independent assembly language. (Almost?) all optimizations are
done on this IR. Some optimizers will look for patterns that stem from some
way a certain programming language is written. BTW, if a totally new
paradigm is introduced that no optimizer recognizes it will either be slow
or take away time to improve some existing optimizer, e.g. the optimizer
for std::visit. There is not magically more programmers for a compiler if
you introduce a new feature.
********Answer********
1.Correction(I know you are more smart but hear me out): that is why I am
introducing a new value type, like take rvalue as an example:
1.Rvalues get the promised move semantics.
2. They have gurrentied optimizations like copy elision.
3.you can provide overloads to functions so as to treat rvalues differently.
So while rvalues aren't optimized, they have unique semantics that make
them efficient, the same go to my construct. I don't want to rely on
backends, but rather rely on semantics(c++ move).
2. Std::visit is the opposite of what we should try to fix because its
optimizations aren't based on semantic promises, but rather compiler
backends.
3. A new paradigm will not hurt performance, if it allows uses to simply
provide their own semantics for it and gurrentie behaviour for it(in this
case compiler generating all code for every path through what ever
technique it sees fit, even if it's vtables).
********Answer********
You are also mixing some concepts: virtual member functions are for runtime
polymorphism. I’m not sure if you are aware that compilers can optimize the
vtables out if it can figure out the type of an object at compile time.
std::variant with std::visit is compile time polymorphism. virtual member
functions don’t matter in this context at all. And std::move also works
with std::variant. As with many things in life you need to weigh the pros
and cons of a certain solution. Yes, currently we don’t have solution that
has all the advantages of both runtime and compile time polymorphism. But,
in 99% of the cases this is fine.
********Answer********
1.Std::move does not work with std::variant unless the destination is a
std::variant itself, so basically you are locked with std variant for that
regard.
2.std::visit is somewhat runtime polymorphism, like fine it generates the
scaffolding st compile time but it is used to make anonymous unions smart,
which might technically(in the standard maybe) not be polymorphism but in
practice is.
3.90% of cases:
1.I can't use templates with std::variant.
2. Can't use move semantics with std::variant.
********Answer********
You also mentioned expression templates. You are correct that they don’t
work with runtime polymorphism. However, I don’t see why they wouldn’t work
with std::variant (and I also don’t know any example where we would need
polymorphism with expression templates at all). Unless you mean something
different with expression templates than I do (I know them from Blitz++ and
Eigen) it is still not something normal. I have yet to encounter them
outside of linear algebra libraries. I would claim few C++ programmers know
about this technique or are even able to implement something like this.
Just as I said: Not normal! (And certainly not necessary in most contexts.)
********Answer********
Sorry for using expression templates as an example instead of templates, I
was very sleepy when writing(didn't sleep for 8 hours at that specific
point), but this applies to all templates. Std::visit can be used to make
std::variants usable with templates, but:
Because it's not a new value type, you can't overload to deal with
std::variant objects in a special way, like you do with prvalues or
xvalues. Which means that you can't have a whole class of semantics and
user defined optimizations (like move semantics in the case of rvalues).
********Answer********
I noticed that now we are restricting your proposal to heterogeneous lists
known at compile time (basically something like std::tuple). I need to make
clear that the examples I have given for motivation (JSON, XML, SQL
queries) are for heterogeneous lists created at runtime! I didn’t find
anything comparable to your problem in the implementation of your Turing
virtual machine when searching for heterogeneous lists. This gives the ball
back to you to motivate why we actually need the proposed feature. It needs
to be useful in more than just one single place to justify standardizing it.
********Answer********
1. My undated proposal isnt a runtime tuple, it's a new expression type
with it's own semantics and user defined optimizations.
2. I proposed this because my main file in my virtual Turing machine is
https://github.com/HjaldrKhilji/The-Turing-virtual-machine/blob/main/Output_modules/src/helper_option_templates_for_arithmetic_related_options.cpp
And in this file, you can see the code bloat caused by trying to manage all
the containers that are used as type (information)storage facilities.
********Answer********
One thing should also be clear for standardization: syntactic sugar,
especially if you don’t like the look of existing solutions, is not a sole
reason for standardization. Neither is verbosity; C++ programmers are used
to not having the nicest syntax around (the main reason being backwards
compatibility).
********Answer********
My updated proposal is about gurrentied semantics and the room for the
users to provide a whole class of optimizations by overloading for this new
expression type.
********Answer********
The only acceptable reason I see so far is that std::visit is (supposedly)
not well enough optimized in one out of three major compilers. This does
not prove that the problem is inherent to std::visit and cannot be
optimized. It also does not matter that you don’t like how switch
statements look. I’m sure that if instead of indexes you provide an enum
class compilers will use an indexed approach if they figure out it is the
optimal solution (I’m quite certain they have this optimization potential
built in). template for has already been mentioned as a way to reduce the
necessary boiler plate code you need to write. And contrary to what you
claimed, reflection might make this even easier. In the long run we will
get something like queue injection. Currently, you most likely could use
reflection to generate source code in a separate file (see Herb Sutter’s
last talk about C++26’s reflection features).
********Answer********
1.std::visit is not good because it doesn't provide the guaranteed
semantics (as I said) and room for user defined optimizations.
2. The "template for" is precisely just a syntactical construct with no new
value types or semantics.
3.Reflection won't provide newer value types that have new semantics .
In short: gurrentied semantics is the golden word in c++.
********Answer********
I do know the narrative that providing more context to the compiler should
make it easier to optimize. It is said that this why we write in high level
languages. From what little I do understand about compilers this statement
is quite theoretical and academic; it is not how real compilers work. You
should show how we write code today and how it could be improved with a new
syntax. And it should be in real world situations and not just some tiny
toy examples (which you already provided). So far, there is just one real
world use case of your Turing virtual machine. We need more than that to
understand that this feature is useful in general.
********Answer********
1. Current code:
Std::visit([](auto &&arg){
Func_a(arg)
}, variant_obj);
/*Vector of objects reliant on this pattern(to keep the example short for
your sake)*/
2. New code:
{List_of_elements}select_name(index_t index)
Func_a(select_name)
//Why is it better? Func_a can provide:
1.overloads for this new expression type.
2.can provide gurrentied optimizations just like rvalues do (I really hope
we move to the discussion for that)
********Answer********
Mr.Sebastian asked:
>This is my "standard approach" made to look a little more how it might
actually be implemented. I don't really know how much C++ you know!
The standard approach:
class Storage
{
public:
class Data {// TBD };
class Key {// TBD};
inline void put (const Key &, const Data &) {
storage[discriminator(data)].put(data);}
Data get (const Key &) const { return
storage[discriminator(data)].get(data);}
private:
int discriminator (const Data &) { // do something}
class Impl
{
public:
virtual void put (const Key &, const Data &) = 0;
virtual Data get (const Key &) const = 0;
};
class FlavorOne : public Impl
{
private:
void put (const Key &, const Data &) override {// do something}
Data get (const Key &) const override {//do something}
std::vector<Data> data;
};
FlavorOne flavorOne;
class FlavorTwo : public Impl
{
private:
void put (const Key &, const Data &) override {// do something}
Data get (const Key &) const override {//do something}
std::list<Data> data;
};
FlavorTwo flavorTwo;
class FlavorThree : public Impl
{
private:
void put (const Data &) override {// do something}
Data get () const override {//do something}
std::deque<Data> data;
};
FlavorThree flavorThree;
std::array<Impl &, 3> storage(flavorOne, flavorTwo, flavorThree)
};
Usage:
Storage myData;
Storage::Key key;
Storage::Data data;
myData.put(key, data);
auto someData = myData.get(data);
1) It is not verbose in either the implementation or usage.
2) Each "flavor" need only adapt the Impl interface to it's own container.
3) The only overhead that is introduced relative to other possible
approaches are a virtual function call per method and one indirection per
method (due to Impl & in std::array).
4) Different "flavors" can be introduced at any time. The only change other
than writing a simple adapter class is one line in the Storage class.
5) Obviously, Storage can be even more generalized by putting it into a
template.
For you to make a case for any addition to the standard, it is my opinion
that you will need a compelling argument that your addition is better than
the above approach.
********Answer********
1. It's verbose because there are no new expressions hence no guaranteed
semantics, which makes code hard to reason. For example constants help you
reason and gurrentied certain semantics that can only be removed with const
cast.
2. It's inefficient because it has no guaranteed semantics optimizations
from the language, and the user can't provide optimizations as well( but he
can do so for rvalues using move semantics).
3. You can't use it move these objects.
4. You can't pass these objects as template arguments (virtual functions
can't be templates).
********Answer********
Hope this answers your questions, and please keep on giving feedback, I
enjoy them, thank you ❤️❤️❤️❤️❤️.
Personal motivations:
I love c++, even spend 9 whole months learning it, and I want to pursue
advanced(full iso draft and some math books before that) c++, but while
doing that, I want c++ to be what I dream of(a metaprogramming heaven)
On Sun, 5 Apr 2026, 1:43 am Steve Weinrich via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> Hi Muneem,
>
> This is my "standard approach" made to look a little more how it might
> actually be implemented. I don't really know how much C++ you know!
>
> The standard approach:
>
> class Storage
> {
> public:
> class Data {// TBD };
> class Key {// TBD};
>
> inline void put (const Key &, const Data &) {
> storage[discriminator(data)].put(data);}
> Data get (const Key &) const { return
> storage[discriminator(data)].get(data);}
>
> private:
> int discriminator (const Data &) { // do something}
>
> class Impl
> {
> public:
> virtual void put (const Key &, const Data &) = 0;
> virtual Data get (const Key &) const = 0;
> };
>
> class FlavorOne : public Impl
> {
> private:
> void put (const Key &, const Data &) override {// do something}
> Data get (const Key &) const override {//do something}
>
> std::vector<Data> data;
> };
>
> FlavorOne flavorOne;
>
> class FlavorTwo : public Impl
> {
> private:
> void put (const Key &, const Data &) override {// do something}
> Data get (const Key &) const override {//do something}
>
> std::list<Data> data;
> };
>
> FlavorTwo flavorTwo;
>
> class FlavorThree : public Impl
> {
> private:
> void put (const Data &) override {// do something}
> Data get () const override {//do something}
>
> std::deque<Data> data;
> };
>
> FlavorThree flavorThree;
>
> std::array<Impl &, 3> storage(flavorOne, flavorTwo, flavorThree)
> };
>
> Usage:
>
> Storage myData;
>
> Storage::Key key;
> Storage::Data data;
>
> myData.put(key, data);
>
> auto someData = myData.get(data);
>
> 1) It is not verbose in either the implementation or usage.
> 2) Each "flavor" need only adapt the Impl interface to it's own container.
> 3) The only overhead that is introduced relative to other possible
> approaches are a virtual function call per method and one indirection per
> method (due to Impl & in std::array).
> 4) Different "flavors" can be introduced at any time. The only change
> other than writing a simple adapter class is one line in the Storage class.
> 5) Obviously, Storage can be even more generalized by putting it into a
> template.
>
> For you to make a case for any addition to the standard, it is my opinion
> that you will need a compelling argument that your addition is better than
> the above approach.
>
> Cheers,
> Steve
>
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of
> Marcin Jaczewski via Std-Proposals
> Sent: Saturday, April 4, 2026 6:22 AM
> To: marcinjaczewski86_at_[hidden]; std-proposals <
> std-proposals_at_[hidden]>; Muneem <itfllow123_at_[hidden]>
> Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
> Subject: Re: [std-proposals] Fwd: Extension to runtime polymorphism
> proposed
>
> Please learn how to properly reply to emails instead of duplicating it two
> times as it is impossible to properly answer them on a mailing list.
>
> sob., 4 kwi 2026 o 14:16 Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
> napisał(a):
> >
> > sob., 4 kwi 2026 o 13:32 Muneem <itfllow123_at_[hidden]> napisał(a):
> > >
> > > Thanks for your response!
> > > The fact that it can create code bloat is exactly why I can't use
> branching statements or std::visit, but with a new construct, the compiler
> knows if it is too expensive to optimize, it it needs to generate a
> vtables, or what ever it wants to do. If it's too expensive at compile time
> then it's gonna use vtables because we are leaving it to the compiler. The
> point is that the compiler has total control. The alternative in my project
> was to use AI to generate switch case statements automatically for me,
> which I had to read and fix issues in, so I would rather trust the compiler
> than AI.
> >
> > The your whole point is moot, when it creates vtable or any function
> > calls it will tank performance in tight loops.
> > You simply try to solve the wrong problem. Proper solutions do not
> > need any switches or calls in tight loops then overhead from
> > `std::visit` or function pointers do not matter as it is done only
> > once per 10000 iterations.
> >
> > >
> > > Again, thanks for your response ❤️ ❤️
> > >
> > >
> > > Sorry for my late reply:
> > > I couldn't sleep for 3 Hours and just saw your reply after I decided
> to use my phone for a few minutes.
> > >
> > > On Sat, 4 Apr 2026, 2:14 pm Marcin Jaczewski, <
> marcinjaczewski86_at_[hidden]> wrote:
> > >>
> > >> pt., 3 kwi 2026 o 01:53 Muneem via Std-Proposals
> > >> <std-proposals_at_[hidden]> napisał(a):
> > >> >
> > >> > One last email (please forgive me for sending twice at once, but I
> think that I didn't get your question so I wanted to answer it properly):
> > >> > hope this is what you asked for:
> > >> > // Current C++:
> > >> > #include <variant>
> > >> > #include <iostream>
> > >> > #include<string>
> > >> >
> > >> > struct A { int get() { return 1; } }; struct B { std::string
> > >> > get() { return "love C++";} }; struct C { double get() { return
> > >> > 2.1; } };
> > >> >
> > >> > struct data_accessed_through_visit {
> > >> > static std::variant<A, B, C> obj;
> > >> >
> > >> > inline void operator()(int) {
> > >> > std::visit([](auto&& arg) {
> > >> > std::cout<< arg.get();
> > >> > }, obj);
> > >> > }
> > >> > };
> > >> > //proves that std visit is too verbose and slow (too
> > >> > hard/impractical to optimize) for this task what about switches,
> enjoy the look for yourself(while imagining the look if this were repeated
> multiple times over hundreds of case statements):
> > >> > struct data_switched {
> > >> > inline void operator()(int index) {
> > >> > switch(index) {
> > >> > case 0: std::cout<<1;
> > >> > case 1: std::cout<<"love C++";
> > >> > case 2: std::cout<<2;
> > >> > default: return -1;
> > >> > }
> > >> > }
> > >> > };
> > >> >
> > >> > fix:
> > >> > struct data_indexed {
> > >> > { 1, "love C++", 2} return_indexed_value(std::size_t index); //A
> > >> > last value can be added to express what is to be returned if the
> index is out of range, that would be awesome because the compiler can even
> optimize that check.
> > >> > inline void operator()(int index) {
> > >> > std::cout<<return_indexed_value(index);
> > >> > }
> > >> > }
> > >> > sorry for sending two emails at twice, i just had to clarify myself
> one last time.
> > >> >
> > >>
> > >> Ok, I think your proposal is dead in water right now.
> > >> Line like:
> > >> ```
> > >> std::cout<<return_indexed_value(index);
> > >> ```
> > >> need to create template context in normal function and this is hard
> > >> to do in some compilers.
> > >> If you follow standardization papers you would see that recent
> > >> proposals for structured binding int packs were unavailable in
> > >> normal functions and are only available in templates. This means
> > >> you would not be able to use it in normal functions.
> > >>
> > >> Beside code like
> > >> ```
> > >> std::cout<<return_indexed_value_i(i) <<return_indexed_value_j(j)
> > >> <<return_indexed_value_k(k) <<return_indexed_value_l(l); ``` will
> > >> be very hard to optimize for the compiler as it has `n^4` possible
> > >> paths. Each need one be created creating a lot of code bloat and
> > >> reception of similar parts that can't be unified as each type is
> > >> slightly diffrent.
> > >>
> > >> >
> > >> > On Fri, Apr 3, 2026 at 4:09 AM Muneem <itfllow123_at_[hidden]> wrote:
> > >> >>
> > >> >> I am really really sorry for sending a flood of emails. As for
> > >> >> the example, it's in the end of this proposal file, please feel
> free to change it physical or by contributing to it on my GitHub. The
> reason that I thought sending a lot of emails is a good idea is because we
> have short attention spans so I wanted to instantly answer your questions
> while you still have it in your minds. If you want, we can calloborate on
> my GitHub on this feature or on your's (I am comfortable either way and on
> any time of the day (except when I am sleeping)) The link and the file is:
> > >> >> https://github.com/HjaldrKhilji/Future-potential-ISO-porposals/b
> > >> >> lob/main/Extension%20to%20runtime%20polymorphism.txt
> > >> >> The example clearly shows that just like the spaceship operator,
> showing intent is always better and valuable. I have yet to define detailed
> features of this new syntax (ie, Const and volatile qualifications, or even
> potential thread policies for a single access), this is because I don't
> know what the comcencess is. Technically, this can be solved a billion
> ways, but right now the solution is minimal because I didn't convince
> anyone to propose a solution themselves.
> > >> >> Again, sorry for sending too much emails, I thought that you guys
> use AI to summarize all my points into short concise ones before reading my
> raw emails. I use this techniques when talking to foreigners that use
> confusing proverbs. Again, I should've known better so I am really really
> sorry.
> > >> >>
> > >> >>
> > >> >> On Fri, 3 Apr 2026, 3:52 am Jens Maurer, <jens.maurer_at_[hidden]>
> wrote:
> > >> >>>
> > >> >>> Hi!
> > >> >>>
> > >> >>> May I suggest that you stop your habit of sending multiple
> > >> >>> rapid-fire responses to the same e-mail?
> > >> >>>
> > >> >>> Take a breath, take a good night's sleep, and take another
> > >> >>> breath before replying to an e-mail. Then, compose that e-mail
> > >> >>> as a draft, take another night, and re-read it the next day.
> > >> >>> Remember, there are orders of magnitude more people you want to
> > >> >>> read your e-mail than there are who writes it (just you, I'd
> > >> >>> guess), so you should make it as easy as possible for those
> > >> >>> people to read your utterances.
> > >> >>>
> > >> >>> Despite the flurry of e-mails, I have not yet seen a simple
> > >> >>> example showing a use of the facility you wish to have (it
> > >> >>> doesn't have to compile with current compilers), and a
> > >> >>> comparison with the (most obvious) code I would need to write
> > >> >>> without the facility you wish to have.
> > >> >>>
> > >> >>> Jens
> > >> >>>
> > >> >>>
> > >> >>> On 4/2/26 21:20, Muneem via Std-Proposals wrote:
> > >> >>> > std::array<int, 3> array_1 = { 1,2,3 }; is also global
> variable, but the ternary/subcript operator statements dont have a hard
> time figuring it out.
> > >> >>> > regards, Muneem.
> > >> >>> >
> > >> >>> >
> > >> >>> > On Fri, Apr 3, 2026 at 12:18 AM Muneem <itfllow123_at_[hidden]
> <mailto:itfllow123_at_[hidden]>> wrote:
> > >> >>> >
> > >> >>> > >why is std::variant object static
> > >> >>> > I made the std::variant static because the array that I was
> getting was also a global variable, infact even when I make the class
> objects return an array variable instead of a constant in that
> std::variant, the rise in latency is almost 0 because the latency of
> std::visit itself is around 470 ns. Again, context and intent are the
> golden words for any compiler.
> > >> >>> > regards, Muneem
> > >> >>> >
> > >> >>> > On Fri, Apr 3, 2026 at 12:14 AM Muneem <
> itfllow123_at_[hidden] <mailto:itfllow123_at_[hidden]>> wrote:
> > >> >>> >
> > >> >>> > So, I am sorry for confusing you, but the think is that
> currently, you need std::visit or branching to index homogeneous values
> with a runtime index, this means that the context and intent given to the
> compiler is minimal, where as for something like template inlining, the
> compiler has a lot of context and intent, from compiler optimization flags
> to instantiation time (which can be delayed till link time for the linker,
> which can lead to even better optimizations), to the context of defining
> the template definition, to the context of argument dependent lookup even,
> which for templates is even more flexible since it can loop for it in any
> namespace to find the most perfect match, which again gives the compiler
> more information. The goal is to give compiler context and intent so that
> it can find the best time to optimize (any phase in compilation or
> linkage), and it knows as much as possible on how to optimize. here are the
> bench marks in visual studio 2026
> > >> >>> > Time (ns) for switch: 97
> > >> >>> > Time (ns) for visit: 534
> > >> >>> > Time (ns) for ternary: 41
> > >> >>> > Time (ns) for subscript: 61
> > >> >>> >
> --
> Std-Proposals mailing list
> 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
>
From: Muneem <itfllow123_at_[hidden]>
Date: Sun, 5 Apr 2026, 6:25 am
Subject: Re: [std-proposals] Fwd: Extension to runtime polymorphism proposed
To: <std-proposals_at_[hidden]>
Hi!
Thank you so so much for your feedbacks ❤️❤️❤️.
I woke up after a 6 hour nap (I couldn't sleep anymore). I will first give
a short response to expand on the problem, then my solution, before
response to every welcomed feedback:
Problem:
So imagine a base class (as Steve shows):
class Storage
{
public:
class Data {// TBD };
class Key {// TBD};
inline void put (const Key &, const Data &) {
storage[discriminator(data)].put(data);}
Data get (const Key &) const { return
storage[discriminator(data)].get(data);}
private:
int discriminator (const Data &) { // do something}
class Impl
{
public:
virtual void put (const Key &, const Data &) = 0;
virtual Data get (const Key &) const = 0;
};
class FlavorOne : public Impl
{
private:
void put (const Key &, const Data &) override {// do something}
Data get (const Key &) const override {//do something}
std::vector<Data> data;
};
FlavorOne flavorOne;
********Problem with this********
1.You can't instantiate templates of the right derieve class using class
base class reference/pointers. Why? Because virtual functions can't be
templates. This is a sore thumb that was the last straw for my virtual
machine code.
2.You can't move a derived class object.
3.it is verbose because:
1. templates don't work
2.moves don't work (hence gonna have to do optimizatioms myself)
3 every operator that you want to use polymorphically has to be a member
function.
4.The abstract tree doesn't provide intent, it just shows and interface
that is implemented by multiple classes, which is like expecting compilers
to move data from lvalue references instead of simply using rvalue
references.
5.types of each override member function has to strictly match, like unlike
compile time template instantion where every type argument provides
fullfills a specific concept/requirement, this requires the exact interface
for each overriden function.
6. You can't provide function overloads that take a pointer and know it's a
polymorphic interface to any object, which again not only hides intent but
doesn't allow you to overload based on polymorphic objects, in to provide a
whole class of optimizations that apply to polymorphic objects or at least
to provide optimizations like std move that already exist.
********Problem with this********
********Solution********
1.provide a new construct that:
{1, std::string{}, obj2} select_name(1);
1. The select_name itself can or cannot(based on what you guys see fit) be
a new expression type.
2. The values inside HAVE(for the advantages to work) a new expression type.
****The advantages of the second point:****
1. Can be passed to templates to instantiate a template where just like
normal types, it can be passed to the templates that are called by that
template.
2.You can use move operations.
3.Is not verbose because it doesn't have the same issues
abstract/polymorphic class Hirearchies do.
4. Provides intent on a abstract tree level because it's a new expression
type which can (just like how rvalues gurrentied(copy elision) and provide
optimizations(move semantics)) can also with time have optimizations
provided to it by both gurrentied and new optimization semantics (similiar
to how functions(especially constructors) can be overloaded to take rvalue
references to optimize code).
5. No type needs to match, just like templates, all members functions used
must be provided by each type, and each type should be able to be passed to
any function that an object at any index can be passed to
6. Specific function overloads can be provided to provide a class of
optimizations and make the code scream the intent that here an
heterogeneous set element is passed, so what can we do to make it optimal.
********Solution********
Questions to ponder on:
1.why were rvalues introduced when you or the compiler backend can do it
thenselves?
2. Why were spaceship operators introduced when you can do it yourself?
3. Why do any new language construct in any human language exist? (Hint:
the more constructs in a language, the more you can change your writing to
target with any particular group that you want to target. For programmers
it's the same if constructs are represented on an abstract tree level)
4. C++ Is really good at metaprogramming, but not for polymorphic objects,
so isn't that an issue?hint: if only this is fixed then imagine everyone
writing Metaprograms only, like I love metaprogramming because of how fast
it feels, faster than writing python.
****Answers to all (defense in long form)*****
Mr. Simon asked:
>I feel like you are misunderstanding how compilers work (I am also not a
professional in this field). From my understanding modern compilers don’t
do much optimization of the AST (though this is different for JIT
compilers). LLVM has several different frontends for different languages,
but the backend is the same. In a first step the programming language is
translated to IR (intermediate representation). This is much like an
architecture independent assembly language. (Almost?) all optimizations are
done on this IR. Some optimizers will look for patterns that stem from some
way a certain programming language is written. BTW, if a totally new
paradigm is introduced that no optimizer recognizes it will either be slow
or take away time to improve some existing optimizer, e.g. the optimizer
for std::visit. There is not magically more programmers for a compiler if
you introduce a new feature.
********Answer********
1.Correction(I know you are more smart but hear me out): that is why I am
introducing a new value type, like take rvalue as an example:
1.Rvalues get the promised move semantics.
2. They have gurrentied optimizations like copy elision.
3.you can provide overloads to functions so as to treat rvalues differently.
So while rvalues aren't optimized, they have unique semantics that make
them efficient, the same go to my construct. I don't want to rely on
backends, but rather rely on semantics(c++ move).
2. Std::visit is the opposite of what we should try to fix because its
optimizations aren't based on semantic promises, but rather compiler
backends.
3. A new paradigm will not hurt performance, if it allows uses to simply
provide their own semantics for it and gurrentie behaviour for it(in this
case compiler generating all code for every path through what ever
technique it sees fit, even if it's vtables).
********Answer********
You are also mixing some concepts: virtual member functions are for runtime
polymorphism. I’m not sure if you are aware that compilers can optimize the
vtables out if it can figure out the type of an object at compile time.
std::variant with std::visit is compile time polymorphism. virtual member
functions don’t matter in this context at all. And std::move also works
with std::variant. As with many things in life you need to weigh the pros
and cons of a certain solution. Yes, currently we don’t have solution that
has all the advantages of both runtime and compile time polymorphism. But,
in 99% of the cases this is fine.
********Answer********
1.Std::move does not work with std::variant unless the destination is a
std::variant itself, so basically you are locked with std variant for that
regard.
2.std::visit is somewhat runtime polymorphism, like fine it generates the
scaffolding st compile time but it is used to make anonymous unions smart,
which might technically(in the standard maybe) not be polymorphism but in
practice is.
3.90% of cases:
1.I can't use templates with std::variant.
2. Can't use move semantics with std::variant.
********Answer********
You also mentioned expression templates. You are correct that they don’t
work with runtime polymorphism. However, I don’t see why they wouldn’t work
with std::variant (and I also don’t know any example where we would need
polymorphism with expression templates at all). Unless you mean something
different with expression templates than I do (I know them from Blitz++ and
Eigen) it is still not something normal. I have yet to encounter them
outside of linear algebra libraries. I would claim few C++ programmers know
about this technique or are even able to implement something like this.
Just as I said: Not normal! (And certainly not necessary in most contexts.)
********Answer********
Sorry for using expression templates as an example instead of templates, I
was very sleepy when writing(didn't sleep for 8 hours at that specific
point), but this applies to all templates. Std::visit can be used to make
std::variants usable with templates, but:
Because it's not a new value type, you can't overload to deal with
std::variant objects in a special way, like you do with prvalues or
xvalues. Which means that you can't have a whole class of semantics and
user defined optimizations (like move semantics in the case of rvalues).
********Answer********
I noticed that now we are restricting your proposal to heterogeneous lists
known at compile time (basically something like std::tuple). I need to make
clear that the examples I have given for motivation (JSON, XML, SQL
queries) are for heterogeneous lists created at runtime! I didn’t find
anything comparable to your problem in the implementation of your Turing
virtual machine when searching for heterogeneous lists. This gives the ball
back to you to motivate why we actually need the proposed feature. It needs
to be useful in more than just one single place to justify standardizing it.
********Answer********
1. My undated proposal isnt a runtime tuple, it's a new expression type
with it's own semantics and user defined optimizations.
2. I proposed this because my main file in my virtual Turing machine is
https://github.com/HjaldrKhilji/The-Turing-virtual-machine/blob/main/Output_modules/src/helper_option_templates_for_arithmetic_related_options.cpp
And in this file, you can see the code bloat caused by trying to manage all
the containers that are used as type (information)storage facilities.
********Answer********
One thing should also be clear for standardization: syntactic sugar,
especially if you don’t like the look of existing solutions, is not a sole
reason for standardization. Neither is verbosity; C++ programmers are used
to not having the nicest syntax around (the main reason being backwards
compatibility).
********Answer********
My updated proposal is about gurrentied semantics and the room for the
users to provide a whole class of optimizations by overloading for this new
expression type.
********Answer********
The only acceptable reason I see so far is that std::visit is (supposedly)
not well enough optimized in one out of three major compilers. This does
not prove that the problem is inherent to std::visit and cannot be
optimized. It also does not matter that you don’t like how switch
statements look. I’m sure that if instead of indexes you provide an enum
class compilers will use an indexed approach if they figure out it is the
optimal solution (I’m quite certain they have this optimization potential
built in). template for has already been mentioned as a way to reduce the
necessary boiler plate code you need to write. And contrary to what you
claimed, reflection might make this even easier. In the long run we will
get something like queue injection. Currently, you most likely could use
reflection to generate source code in a separate file (see Herb Sutter’s
last talk about C++26’s reflection features).
********Answer********
1.std::visit is not good because it doesn't provide the guaranteed
semantics (as I said) and room for user defined optimizations.
2. The "template for" is precisely just a syntactical construct with no new
value types or semantics.
3.Reflection won't provide newer value types that have new semantics .
In short: gurrentied semantics is the golden word in c++.
********Answer********
I do know the narrative that providing more context to the compiler should
make it easier to optimize. It is said that this why we write in high level
languages. From what little I do understand about compilers this statement
is quite theoretical and academic; it is not how real compilers work. You
should show how we write code today and how it could be improved with a new
syntax. And it should be in real world situations and not just some tiny
toy examples (which you already provided). So far, there is just one real
world use case of your Turing virtual machine. We need more than that to
understand that this feature is useful in general.
********Answer********
1. Current code:
Std::visit([](auto &&arg){
Func_a(arg)
}, variant_obj);
/*Vector of objects reliant on this pattern(to keep the example short for
your sake)*/
2. New code:
{List_of_elements}select_name(index_t index)
Func_a(select_name)
//Why is it better? Func_a can provide:
1.overloads for this new expression type.
2.can provide gurrentied optimizations just like rvalues do (I really hope
we move to the discussion for that)
********Answer********
Mr.Sebastian asked:
>This is my "standard approach" made to look a little more how it might
actually be implemented. I don't really know how much C++ you know!
The standard approach:
class Storage
{
public:
class Data {// TBD };
class Key {// TBD};
inline void put (const Key &, const Data &) {
storage[discriminator(data)].put(data);}
Data get (const Key &) const { return
storage[discriminator(data)].get(data);}
private:
int discriminator (const Data &) { // do something}
class Impl
{
public:
virtual void put (const Key &, const Data &) = 0;
virtual Data get (const Key &) const = 0;
};
class FlavorOne : public Impl
{
private:
void put (const Key &, const Data &) override {// do something}
Data get (const Key &) const override {//do something}
std::vector<Data> data;
};
FlavorOne flavorOne;
class FlavorTwo : public Impl
{
private:
void put (const Key &, const Data &) override {// do something}
Data get (const Key &) const override {//do something}
std::list<Data> data;
};
FlavorTwo flavorTwo;
class FlavorThree : public Impl
{
private:
void put (const Data &) override {// do something}
Data get () const override {//do something}
std::deque<Data> data;
};
FlavorThree flavorThree;
std::array<Impl &, 3> storage(flavorOne, flavorTwo, flavorThree)
};
Usage:
Storage myData;
Storage::Key key;
Storage::Data data;
myData.put(key, data);
auto someData = myData.get(data);
1) It is not verbose in either the implementation or usage.
2) Each "flavor" need only adapt the Impl interface to it's own container.
3) The only overhead that is introduced relative to other possible
approaches are a virtual function call per method and one indirection per
method (due to Impl & in std::array).
4) Different "flavors" can be introduced at any time. The only change other
than writing a simple adapter class is one line in the Storage class.
5) Obviously, Storage can be even more generalized by putting it into a
template.
For you to make a case for any addition to the standard, it is my opinion
that you will need a compelling argument that your addition is better than
the above approach.
********Answer********
1. It's verbose because there are no new expressions hence no guaranteed
semantics, which makes code hard to reason. For example constants help you
reason and gurrentied certain semantics that can only be removed with const
cast.
2. It's inefficient because it has no guaranteed semantics optimizations
from the language, and the user can't provide optimizations as well( but he
can do so for rvalues using move semantics).
3. You can't use it move these objects.
4. You can't pass these objects as template arguments (virtual functions
can't be templates).
********Answer********
Hope this answers your questions, and please keep on giving feedback, I
enjoy them, thank you ❤️❤️❤️❤️❤️.
Personal motivations:
I love c++, even spend 9 whole months learning it, and I want to pursue
advanced(full iso draft and some math books before that) c++, but while
doing that, I want c++ to be what I dream of(a metaprogramming heaven)
On Sun, 5 Apr 2026, 1:43 am Steve Weinrich via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> Hi Muneem,
>
> This is my "standard approach" made to look a little more how it might
> actually be implemented. I don't really know how much C++ you know!
>
> The standard approach:
>
> class Storage
> {
> public:
> class Data {// TBD };
> class Key {// TBD};
>
> inline void put (const Key &, const Data &) {
> storage[discriminator(data)].put(data);}
> Data get (const Key &) const { return
> storage[discriminator(data)].get(data);}
>
> private:
> int discriminator (const Data &) { // do something}
>
> class Impl
> {
> public:
> virtual void put (const Key &, const Data &) = 0;
> virtual Data get (const Key &) const = 0;
> };
>
> class FlavorOne : public Impl
> {
> private:
> void put (const Key &, const Data &) override {// do something}
> Data get (const Key &) const override {//do something}
>
> std::vector<Data> data;
> };
>
> FlavorOne flavorOne;
>
> class FlavorTwo : public Impl
> {
> private:
> void put (const Key &, const Data &) override {// do something}
> Data get (const Key &) const override {//do something}
>
> std::list<Data> data;
> };
>
> FlavorTwo flavorTwo;
>
> class FlavorThree : public Impl
> {
> private:
> void put (const Data &) override {// do something}
> Data get () const override {//do something}
>
> std::deque<Data> data;
> };
>
> FlavorThree flavorThree;
>
> std::array<Impl &, 3> storage(flavorOne, flavorTwo, flavorThree)
> };
>
> Usage:
>
> Storage myData;
>
> Storage::Key key;
> Storage::Data data;
>
> myData.put(key, data);
>
> auto someData = myData.get(data);
>
> 1) It is not verbose in either the implementation or usage.
> 2) Each "flavor" need only adapt the Impl interface to it's own container.
> 3) The only overhead that is introduced relative to other possible
> approaches are a virtual function call per method and one indirection per
> method (due to Impl & in std::array).
> 4) Different "flavors" can be introduced at any time. The only change
> other than writing a simple adapter class is one line in the Storage class.
> 5) Obviously, Storage can be even more generalized by putting it into a
> template.
>
> For you to make a case for any addition to the standard, it is my opinion
> that you will need a compelling argument that your addition is better than
> the above approach.
>
> Cheers,
> Steve
>
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of
> Marcin Jaczewski via Std-Proposals
> Sent: Saturday, April 4, 2026 6:22 AM
> To: marcinjaczewski86_at_[hidden]; std-proposals <
> std-proposals_at_[hidden]>; Muneem <itfllow123_at_[hidden]>
> Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
> Subject: Re: [std-proposals] Fwd: Extension to runtime polymorphism
> proposed
>
> Please learn how to properly reply to emails instead of duplicating it two
> times as it is impossible to properly answer them on a mailing list.
>
> sob., 4 kwi 2026 o 14:16 Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
> napisał(a):
> >
> > sob., 4 kwi 2026 o 13:32 Muneem <itfllow123_at_[hidden]> napisał(a):
> > >
> > > Thanks for your response!
> > > The fact that it can create code bloat is exactly why I can't use
> branching statements or std::visit, but with a new construct, the compiler
> knows if it is too expensive to optimize, it it needs to generate a
> vtables, or what ever it wants to do. If it's too expensive at compile time
> then it's gonna use vtables because we are leaving it to the compiler. The
> point is that the compiler has total control. The alternative in my project
> was to use AI to generate switch case statements automatically for me,
> which I had to read and fix issues in, so I would rather trust the compiler
> than AI.
> >
> > The your whole point is moot, when it creates vtable or any function
> > calls it will tank performance in tight loops.
> > You simply try to solve the wrong problem. Proper solutions do not
> > need any switches or calls in tight loops then overhead from
> > `std::visit` or function pointers do not matter as it is done only
> > once per 10000 iterations.
> >
> > >
> > > Again, thanks for your response ❤️ ❤️
> > >
> > >
> > > Sorry for my late reply:
> > > I couldn't sleep for 3 Hours and just saw your reply after I decided
> to use my phone for a few minutes.
> > >
> > > On Sat, 4 Apr 2026, 2:14 pm Marcin Jaczewski, <
> marcinjaczewski86_at_[hidden]> wrote:
> > >>
> > >> pt., 3 kwi 2026 o 01:53 Muneem via Std-Proposals
> > >> <std-proposals_at_[hidden]> napisał(a):
> > >> >
> > >> > One last email (please forgive me for sending twice at once, but I
> think that I didn't get your question so I wanted to answer it properly):
> > >> > hope this is what you asked for:
> > >> > // Current C++:
> > >> > #include <variant>
> > >> > #include <iostream>
> > >> > #include<string>
> > >> >
> > >> > struct A { int get() { return 1; } }; struct B { std::string
> > >> > get() { return "love C++";} }; struct C { double get() { return
> > >> > 2.1; } };
> > >> >
> > >> > struct data_accessed_through_visit {
> > >> > static std::variant<A, B, C> obj;
> > >> >
> > >> > inline void operator()(int) {
> > >> > std::visit([](auto&& arg) {
> > >> > std::cout<< arg.get();
> > >> > }, obj);
> > >> > }
> > >> > };
> > >> > //proves that std visit is too verbose and slow (too
> > >> > hard/impractical to optimize) for this task what about switches,
> enjoy the look for yourself(while imagining the look if this were repeated
> multiple times over hundreds of case statements):
> > >> > struct data_switched {
> > >> > inline void operator()(int index) {
> > >> > switch(index) {
> > >> > case 0: std::cout<<1;
> > >> > case 1: std::cout<<"love C++";
> > >> > case 2: std::cout<<2;
> > >> > default: return -1;
> > >> > }
> > >> > }
> > >> > };
> > >> >
> > >> > fix:
> > >> > struct data_indexed {
> > >> > { 1, "love C++", 2} return_indexed_value(std::size_t index); //A
> > >> > last value can be added to express what is to be returned if the
> index is out of range, that would be awesome because the compiler can even
> optimize that check.
> > >> > inline void operator()(int index) {
> > >> > std::cout<<return_indexed_value(index);
> > >> > }
> > >> > }
> > >> > sorry for sending two emails at twice, i just had to clarify myself
> one last time.
> > >> >
> > >>
> > >> Ok, I think your proposal is dead in water right now.
> > >> Line like:
> > >> ```
> > >> std::cout<<return_indexed_value(index);
> > >> ```
> > >> need to create template context in normal function and this is hard
> > >> to do in some compilers.
> > >> If you follow standardization papers you would see that recent
> > >> proposals for structured binding int packs were unavailable in
> > >> normal functions and are only available in templates. This means
> > >> you would not be able to use it in normal functions.
> > >>
> > >> Beside code like
> > >> ```
> > >> std::cout<<return_indexed_value_i(i) <<return_indexed_value_j(j)
> > >> <<return_indexed_value_k(k) <<return_indexed_value_l(l); ``` will
> > >> be very hard to optimize for the compiler as it has `n^4` possible
> > >> paths. Each need one be created creating a lot of code bloat and
> > >> reception of similar parts that can't be unified as each type is
> > >> slightly diffrent.
> > >>
> > >> >
> > >> > On Fri, Apr 3, 2026 at 4:09 AM Muneem <itfllow123_at_[hidden]> wrote:
> > >> >>
> > >> >> I am really really sorry for sending a flood of emails. As for
> > >> >> the example, it's in the end of this proposal file, please feel
> free to change it physical or by contributing to it on my GitHub. The
> reason that I thought sending a lot of emails is a good idea is because we
> have short attention spans so I wanted to instantly answer your questions
> while you still have it in your minds. If you want, we can calloborate on
> my GitHub on this feature or on your's (I am comfortable either way and on
> any time of the day (except when I am sleeping)) The link and the file is:
> > >> >> https://github.com/HjaldrKhilji/Future-potential-ISO-porposals/b
> > >> >> lob/main/Extension%20to%20runtime%20polymorphism.txt
> > >> >> The example clearly shows that just like the spaceship operator,
> showing intent is always better and valuable. I have yet to define detailed
> features of this new syntax (ie, Const and volatile qualifications, or even
> potential thread policies for a single access), this is because I don't
> know what the comcencess is. Technically, this can be solved a billion
> ways, but right now the solution is minimal because I didn't convince
> anyone to propose a solution themselves.
> > >> >> Again, sorry for sending too much emails, I thought that you guys
> use AI to summarize all my points into short concise ones before reading my
> raw emails. I use this techniques when talking to foreigners that use
> confusing proverbs. Again, I should've known better so I am really really
> sorry.
> > >> >>
> > >> >>
> > >> >> On Fri, 3 Apr 2026, 3:52 am Jens Maurer, <jens.maurer_at_[hidden]>
> wrote:
> > >> >>>
> > >> >>> Hi!
> > >> >>>
> > >> >>> May I suggest that you stop your habit of sending multiple
> > >> >>> rapid-fire responses to the same e-mail?
> > >> >>>
> > >> >>> Take a breath, take a good night's sleep, and take another
> > >> >>> breath before replying to an e-mail. Then, compose that e-mail
> > >> >>> as a draft, take another night, and re-read it the next day.
> > >> >>> Remember, there are orders of magnitude more people you want to
> > >> >>> read your e-mail than there are who writes it (just you, I'd
> > >> >>> guess), so you should make it as easy as possible for those
> > >> >>> people to read your utterances.
> > >> >>>
> > >> >>> Despite the flurry of e-mails, I have not yet seen a simple
> > >> >>> example showing a use of the facility you wish to have (it
> > >> >>> doesn't have to compile with current compilers), and a
> > >> >>> comparison with the (most obvious) code I would need to write
> > >> >>> without the facility you wish to have.
> > >> >>>
> > >> >>> Jens
> > >> >>>
> > >> >>>
> > >> >>> On 4/2/26 21:20, Muneem via Std-Proposals wrote:
> > >> >>> > std::array<int, 3> array_1 = { 1,2,3 }; is also global
> variable, but the ternary/subcript operator statements dont have a hard
> time figuring it out.
> > >> >>> > regards, Muneem.
> > >> >>> >
> > >> >>> >
> > >> >>> > On Fri, Apr 3, 2026 at 12:18 AM Muneem <itfllow123_at_[hidden]
> <mailto:itfllow123_at_[hidden]>> wrote:
> > >> >>> >
> > >> >>> > >why is std::variant object static
> > >> >>> > I made the std::variant static because the array that I was
> getting was also a global variable, infact even when I make the class
> objects return an array variable instead of a constant in that
> std::variant, the rise in latency is almost 0 because the latency of
> std::visit itself is around 470 ns. Again, context and intent are the
> golden words for any compiler.
> > >> >>> > regards, Muneem
> > >> >>> >
> > >> >>> > On Fri, Apr 3, 2026 at 12:14 AM Muneem <
> itfllow123_at_[hidden] <mailto:itfllow123_at_[hidden]>> wrote:
> > >> >>> >
> > >> >>> > So, I am sorry for confusing you, but the think is that
> currently, you need std::visit or branching to index homogeneous values
> with a runtime index, this means that the context and intent given to the
> compiler is minimal, where as for something like template inlining, the
> compiler has a lot of context and intent, from compiler optimization flags
> to instantiation time (which can be delayed till link time for the linker,
> which can lead to even better optimizations), to the context of defining
> the template definition, to the context of argument dependent lookup even,
> which for templates is even more flexible since it can loop for it in any
> namespace to find the most perfect match, which again gives the compiler
> more information. The goal is to give compiler context and intent so that
> it can find the best time to optimize (any phase in compilation or
> linkage), and it knows as much as possible on how to optimize. here are the
> bench marks in visual studio 2026
> > >> >>> > Time (ns) for switch: 97
> > >> >>> > Time (ns) for visit: 534
> > >> >>> > Time (ns) for ternary: 41
> > >> >>> > Time (ns) for subscript: 61
> > >> >>> >
> --
> Std-Proposals mailing list
> 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-05 01:35:42