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.