sorry for sending two replies at once, but just to make it clear, I see my
proposal as unpolished (really really unpolished) and need your counter
proposal to refine it.
regards,Muneem

On Fri, Apr 3, 2026 at 5:33 AM Muneem <itfllow123_at_[hidden]> wrote:

> I uploaded my latest proposal and I know instruction cache matters, that
> is precisely why switch case statements fail; We need something that gives
> the compiler more context that what we want is subscription a homogenous
> list, or else we would either suffer from massive latency of std::visit or
> the code bloat of switch case statements. I hate both of them, and what I
> want is to give the compiler context to determine what should be done.
> I would really really appreciate for a counter proposal on what could be
> better than the things that I described in my updated proposal.
> Thank you for your feedback!
> regards, Muneem
>
> On Fri, Apr 3, 2026 at 5:27 AM Adrian Johnston via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Regarding: Extension to runtime polymorphism
>>
>> The problem with this kind of thing is that there is also an
>> "instruction cache" as well as a "data cache." Every time you run
>> more code you increase the risk of running off of, or thrashing your
>> instruction cache and taking instruction cache misses instead.
>>
>> I understand the cache problems with virtual functions, but there are
>> problems with too much code bloat as well. Your examples describe
>> creating more cache pressure than just using a virtual function call.
>>
>> (And I wouldn't advise waiting around for the authors of the C++
>> compilers to add JIT. It sounds like the latest standards have put a
>> lot of work in front of them.)
>>
>>
>>
>> On Tue, Mar 31, 2026 at 7:44 AM Jason McKesson via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > On Mon, Mar 30, 2026 at 4:48 PM Muneem via Std-Proposals
>> > <std-proposals_at_[hidden]> wrote:
>> > >
>> > > Recently, I faced some issues in writing code that relied heavily on
>> repetitive branching, which forced me to use AI. This proposal proposes
>> techniques to counter this, in cases where the overhead of single dispatch
>> is highly undesirable.
>> >
>> > Have you considered that what you're trying to do is perhaps not an
>> > effective way to implement whatever that is? And that there's probably
>> > a better way that doesn't require using a `switch` in the middle of
>> > various functions?
>> >
>> > For example, let's take your initial code:
>> >
>> > ```
>> > void push_multiple_to_container(const std::string string_to_read_from,
>> > std::string::size_type* pos) {
>> > switch(static_cast<where_to_push_enum>(
>> >
>> absolute_base::read_from_string<get_integer_for_size<sizeof(where_to_push_enum)>>))
>> > {
>> > case push_to_vector:
>> > implementation_template_function_f(vector,
>> read_content_to_push);
>> > break;
>> > case push_to_deque:
>> > implementation_template_function_f(deque,
>> read_content_to_push);
>> > break;
>> > // ... and so on
>> > }
>> > }
>> > ```
>> >
>> > I don't see where `where_to_push_enum` comes from. Since you're doing
>> > a `static_cast` to it, this is a type. I don't see a template header,
>> > so I'm guessing that this is a member of a template class where
>> > `where_to_push_enum` is provided as a template argument.
>> >
>> > So it stands to reason that you could reduce this function to
>> > something like this:
>> >
>> > ```
>> > implementation_template_function_f(_get_container(),
>> read_content_to_push);
>> > ```
>> >
>> > Where `_get_container` has your switch/case statement and returns this
>> > container. And the containers it can return are appropriate for
>> > calling `implementation_template_function_f`.
>> > --
>> > 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
>>
>