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/blob/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
> >> >>> >