The only reason that I used std::visit and switch was to show that the
current techniques of indexing homogenous values using them don't work.
Indexing is always gonna be easier for the optimizer because of intent
(check the bench marks for -o3)
Regards, Muneem

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

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