Also just because compilers are good, does not mean that we need the extra
compile time overhead. This feature would not break anything, it's just a
extra feature, just like the one that was in the end of the video, which
again, helped compilers with extra ordinary capabilities.
Thanks for your feedback; I hope we can continue ❤️❤️❤️
Regards, Muneem.

On Thu, 2 Apr 2026, 11:36 pm Muneem, <itfllow123_at_[hidden]> wrote:

> >how often does one do that?
> The problem is very extensive, like branching is what we all have to do
> when we are trying to perform a void action or trying to get subscript a
> homegenous value with a runtime index. Branching constructs only give the
> compiler the context on what's going on at the point of use.
>
> On Thu, 2 Apr 2026, 11:33 pm Muneem, <itfllow123_at_[hidden]> wrote:
>
>> Hi!
>> The point that I am trying to make is that the reasons templates can be
>> better inlined/optimized is because you have two contexts: context of
>> declaration, context of instantiation, and context or argument dependent
>> lookup. My proposal is only supposed to provide an alternative that
>> implementations don't see as a technique to maintain the stability of
>> abi's, but rather as a technique to get details to optimize code. Thank of
>> how compiler works:
>> They have a abstract syntax tree, so if there is a contract that has data
>> from multiple sources in it's tree then the compiler has more flexibility
>> to optimize what it wants to.
>> Putting requirements on compilers to optimize std::visit and switch case
>> is worse because it will also result in gurrentied compile time overhead.
>> The goal is to provide a new value type because a new value type will give
>> the compiler a whole new perspective on what it's context(we can add
>> options more contexts than what templates get) is and what the intent is.
>> C++ needs this more than ever.
>>
>> On Thu, 2 Apr 2026, 8:48 pm Thiago Macieira via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On Wednesday, 1 April 2026 22:49:37 Pacific Daylight Time Muneem via Std-
>>> Proposals wrote:
>>> > To revise:
>>> > Purpose of the Proposal:
>>> > 1.This code is intended to replace the need for excessive or "ad hoc"
>>> > branching (such as clumsy, nested switch or if-else statements) when
>>> the
>>> > primary goal is simply to retrieve a value.
>>>
>>> How often does one that? How extensive is the problem?
>>>
>>> > 2. Regarding runtime polymorphism:
>>> > the current implementation almost always leads to the use of vtables.
>>> This
>>> > persists primarily because vtables are designed to keep Application
>>> Binary
>>> > Interfaces (ABI) stable.
>>>
>>> That's a means-to-an-end. The Standard knows nothing about vtables and
>>> about
>>> ABI. You may mention them in your proposal when talking about how
>>> current
>>> implementations' hands are tied, or when discussing how your proposal
>>> would
>>> complement but not break ABI.
>>>
>>> > 3.Enum and Integer Branching:
>>> > When we use enum or integer-based branching, we often fail to provide
>>> the
>>> > compiler with the exact indices that are optimized for value retrieval.
>>> > Instead, the current structure merely tells the compiler that an
>>> integer of
>>> > a certain size must fall within a specific range to execute a range of
>>> > actions. (What switch case and if else statements do). For example,
>>> with
>>> > this new syntax, the compiler would know that any index passed to it is
>>> > merely an index. This of tuples, but tuples accepting runtime indexes.
>>> I
>>> > believe tuples like that would replace the need for adhoc branching.
>>>
>>> You're selling current compilers' capability of optimising short. They
>>> do a
>>> very good job at optimising based on the few values that can be used, in
>>> spite
>>> of a much larger possible range of incoming input. Moreover, CPUs are
>>> also
>>> quite good at speculating ahead, and the branch predictor units are very
>>> good.
>>> Replacing branching with a lookup may or may not be beneficial: it will
>>> depend
>>> on the implementation and the values.
>>>
>>> > 4. The other possible solution (the one to make every function that
>>> has a
>>> > different enum in its signature to not override a function with the
>>> same
>>> > arguments and name, and for that functions to instead be its own
>>> function)
>>> > ,was to make current techniques more flexible. Though that technique
>>> would
>>> > probably require template function specializations to be converted to
>>> > virtual functions by a declaration, to implement.
>>>
>>> That paragraph did not make sense. I can understand each and every word,
>>> but
>>> put together they did not convey a meaning.
>>>
>>> --
>>> 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
>>>
>>