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
>