Date: Sat, 4 Apr 2026 14:43:22 -0600
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
> >> >>> >
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
Received on 2026-04-04 20:43:29