no one asked for this reply but I just wanted to keep the records straight.

Here is why anyone who has reflections in mind (as a base for this
solution) might be wrong:
1.reflectors aren't for subscripting(are a completely different thing(they
are like unions and std::variants)), but rather a better version of
std::visit, so subscripting using reflectors is using the wrong tool for
the wrong solution and dosent send proper intent to the compiler .
2. Even if reflectors were optimized enough to be fast even when I use
proxy objects in it(to act as indexes into a heterogeneous list), the
compiler can't optimize freely without it backfiring(code bloating). Why?
Because my tool has at least two contexts available to it (more if you guys
propose), the context of defining the object, the context of using that
object, and (if the subscript can be user defined objects that can return a
integer through some semantical promise (using concepts to enforce)) the
context of the subscript object and it's type. All this would give enough
context for the compiler to optimize without backfiring, that is to
optimize for the whole project, rather than one expression.
3. Its less verbose and would incur less compile time overhead for more
potential rewards.

Anyone who thought of this is a genius, but I just wanted to clarify on why
he might not be right.




Regards, Muneem.

On Fri, 3 Apr 2026, 7:43 am Muneem, <itfllow123_at_[hidden]> wrote:

> Hi!
> 1. Even if it wasn't(and I was wrong), there are many more
> examples(spaceship operator, constexpr if statements, consteval, the list
> is too big to list all in the open). The point isn't that I am perfect but
> rather that my proposal is right.
> 2. I said what I said because Bjarne Strourstrup in his book (C++
> programming 4th edition, page 675, Section 23.3.2 ) " That point is called
> the first point of instantiation (§26.3.3). The implementation is allowed
> to postpone essentially all checking until the program is linked, and for
> some errors link time is also the earliest point when complete checking is
> possible. Independently of when checking is done, the same set of rules is
> checked. ", but maybe I was wrong.
> 3. I am really really really sorry for sending too many emails.
> 4. In the real world(I know you know more (intel goated) than me but let
> me clarify), you dont have constant, in real world, the index can be real
> time, infact, for anything constant, tuples work even for
> heterogeneous sets. I dont know how you get a constant but if your input is
> coming a real time source then in my opinion it is impossible to make it be
> constant.
> 5. I used the cpu profiling of visual studio 2022
> Time taken for looping 100000000000 times over a line that adds into a
> volatile x from a index in obj read by std::cin:
>
> 17-20s switch 2 minutes 20s for visit, 11 for ternary statements, 20 for
> subscript.
>
> CPU(termed as processer usage in visual studio) usage (in percetager):
> [4-12] percent for switch.
> [8- 20] for std::visit
> [4-9] percent for ternary.
> [4-12] for subscripting.
>
> 6. I updated my proposal so I highly suggest that you ask AI to summarize
> the thing or read it if you will.
>
> 7. I used the cpu profiling of visual studio 2022
> Time taken for looping 100000000000 times over a line that adds into a
> volatile x from a index in obj read by std::cin:
>
> 17-20s switch 2 minutes 20s for visit, 11 for ternary statements, 20 for
> subscript.
>
> CPU(termed as processer usage in visual studio) usage (in percetager):
> [4-12] percent for switch.
> [8- 20] for std::visit
> [4-9] percent for ternary.
> [4-12] for subscripting.
>
> 8. The point on optimization dosent just apply on making subscripting into
> heterogeneous lists like existing indexing, but to rather make a
> syntactic construct that makes certain semantic promises(that I hope you
> guys propose) which would help the compiler optimize it for the specific
> cases where we want a balance between code bloat and runtime performance
> (ie, we dont know which one to use swtich case or std::visit). Adding
> semantical "promises" to constructs make constructs powerful than raw
> assembly. Recall spaceship operators and the fact that they have semantic
> promises(through the return type) that make the compiler know what it can
> expect better, and leads to less verbose code than having to define every
> comparison opreator's default function.
> 9. I do read assembly, but in most real world examples, the assembly can
> vary widely so you cant depend on the assembly code to know if your aproach
> works or not. I showed you the benchmarks, you said that they can lie, so
> can assembly then, like compilers have potential layers of translation
> inside each phase, which coupled with unspecified behaviour can mean that
> assembly can lie.
> 10. My main goal is to get someone to vouch for my proposal and add more
> semantical requirements, not to defend whether templates can be
> instantiated or not.
> 11. The reason why I made std::visit static (in my benchmarks yesterday
> and in the benchmarks on the latest proposal on my github:
> https://github.com/HjaldrKhilji/Future-potential-ISO-porposals/blob/main/Extension%20to%20runtime%20polymorphism.txt)
> was because the variables that the switch and ternary returned were also
> global variables, so I was trying to level the field by making the
> variables global, variant static (but return literals).
> 12.The code that you might find fair, but I find too much in favor of
> std::visit, but std::visit still loses:https://godbolt.org/z/aP488n1cj,
> benchmarks dont change accoridng to visual studio profiler.
> 13. I used std::variant to show that just in case someone asks me to use
> proxies or a type erasure system like using references in std:variant or
> using virtual functions, the performance would be bad and the code would
> still be verbose, leaving only to the verbose switch/if/ternary statements.
> 14. The microbench is exactly what I am trying to prove that a new
> syntactic construct won't just help with a few nanoseconds, but help with
> many cases of the same thing to work better in conjunction with the rest of
> the project.
> 15. The reason that I didn't make the fact that (according to you) the
> switch statement had the outer loop optimized to 3 loops does dont branch
> is because that argument is pointless, my point isn't that why switch
> statements are better, but rather on why my solution is better, and this
> benchmark was to show that std::visit and polymorphism does not address all
> problems that manual branching has (code bloat (potentially) causing worse
> performance than redirection (huge respect and credit to adrian for making
> me remember this point)).
> 16. Again, if I paste a whole large example, I wouldn't convey my point
> which is that we need something to convey intent better when subscripting
> heterogeneous sets.
> std::visit fails, and switch case statements backfire because of potential
> code bloat. The benchmark was to show that the compiler can optimize
> performance for smaller projects where It knows that it can be faster in
> one specific case, a new construct would help the compiler know what the
> goal of using that construct is, so that it can make it faster (if it can)
> or even make it slower if it helps the rest of the project. Again, the
> construct wont make a small example fast, but rather a whole ton of. The
> reason that I didn't show a real world example for switch statements is
> that I am not arguing for switch statements to be used everywhere, but
> rather the opposite.
>
>
> On Fri, Apr 3, 2026 at 6:31 AM Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Thursday, 2 April 2026 12:32:34 Pacific Daylight Time Muneem via Std-
>> Proposals wrote:
>> > It's different for templates because the linker has to plug in some
>> type,
>>
>> No. There is no linker in template expansion.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>