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