---------- Forwarded message ---------
From: Muneem <itfllow123_at_[hidden]>
Date: Wed, Apr 1, 2026 at 9:43 AM
Subject: Re: [std-proposals] Extension to runtime polymorphism proposed
To: Chris Ryan <chrisr98008_at_[hidden]>


Hi, and thanks for your reply

I feel like you don't understand what I mean by polymorphism. What I meant
is that the current polymorphism is limited to function calls, but any
other kind of branching that you want to avoid using these techniques would
lead to slow and verbose code. Also, the issue isn't the amount of
instructions; it is the amount of memory branching. Recall that ram is very
slow when compared to the CPU, so you would want data to be close to each
other, and the current single dispatch breaks that, not to mention the
overhead of a function call. The point is that current polymorphism can be
amplified if we provide a JIT that makes current polymorphism less verbose
with the same performance. The JIT should also allow virtual table entries
to be indexes by value instead of just argument types and function name. A
better solution is the most radical one, which is a new value type, which
would be polymorphism in the sense that it's a value that you intialize it
one, and you can choose any value using an index. It would be similiar to
tuple indexing but far less adhoc, ugly, and can be inlined (multiple
indexing operations can be inlined to a single). Think of it this way,
macros existed before to allow for function inlining and templates, but it
was unsafe, ugly, and wasent obvious to the reason, but thanks to inline
functions, we have expression templates. Hope this answers you, and thank
you for your feedback ❤️❤️❤️❤️. I love interacting with all of you.

Before you respond with another loved response, think of this paragraph:
One of the main issues with tuple based branching for my case is that then
I can't use other compile polymorphism facilities (templates) and I can't
use runtime values to index tuples, so another possible solution might be
to enhance c++ with tuples that can accept non constexpr indexes.

On Wed, 1 Apr 2026, 9:24 am Chris Ryan, <chrisr98008_at_[hidden]> wrote:

> Abdul,
>
> > current form of polymorphism is not only slow, but only verbose,
> ????
>
> Dynamic Polymorphism is only *slightly *slower than a non-polymorphic
> function call.
> Just an indirect lookup and the branch. Basically an assembly instruction.
> And I have no idea what you are saying about it being verbose.
>
> Dynamic Polymorphism works for unknown derived types.
> I could not follow much of your incomplete sample code but it looks like
> it was dealing with limited fixed types.
> It also being more than just an assembly instruction must be very much
> slower.
>
>
> On Tue, Mar 31, 2026 at 9:00 PM Muneem via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> The current form of polymorphism is not only slow, but only verbose, a
>> new value type would help the most, though a just in time compiler would be
>> a cherry on the top for the current template capabilities of c++. this is
>> because it would provide some notion of extended templates or runtime
>> templates, and would make most cases of unsafe type erasure techniques
>> obsolete.
>>
>>
>>
>>
>> Regards, muneem
>>
>> On Wed, 1 Apr 2026, 8:56 am Muneem, <itfllow123_at_[hidden]> wrote:
>>
>>> Hi!
>>> I am really really sorry for the ambiguous response, I meant, overrided*
>>> ;
>>> This further supports my notion of a just in time compiler for such
>>> cases of overriding.
>>> I am really really sorry for using the word overloading instead of
>>> overriding, and my example did take enum_t as template argument and a enum
>>> of that arg as function arguments.
>>>
>>>
>>> On Wed, 1 Apr 2026, 8:41 am Jason McKesson via Std-Proposals, <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> On Tue, Mar 31, 2026 at 9:23 PM Muneem via Std-Proposals
>>>> <std-proposals_at_[hidden]> wrote:
>>>> >
>>>> > Responding to Mr. Jason McKesson's near and dear feedback dated
>>>> [31-3-2026] (I had some issues with my digest settings, so I'm replying
>>>> manually):
>>>> >
>>>> > First, I would like to clarify that the reason I responded late was
>>>> because I couldn't find his mail until someone was kind enough to remind me
>>>> that your (McKesson's) response did, in fact, exist.
>>>> >
>>>> > I did think of that; in fact, that's the main reason why I couldn't
>>>> sleep, to be honest with you. Let me break it down on why I didn't use the
>>>> suggested technique:
>>>> >
>>>> > It can't technically work the way you would expect, since functions
>>>> can be overloaded based on enums, and if it can't be overloaded, then it
>>>> can't have different return types. Why does this matter? Well, the STL
>>>> containers don't share a common container base, so making this work would
>>>> require you to add a base class with virtual functions like pop_back(),
>>>> at(), etc. Then you would have to implement them for each derived class and
>>>> then return the appropriate derived class.
>>>>
>>>> Maybe your example was missing something, but taking it as it was
>>>> presented, the enum in question was a template parameter. And a class
>>>> template parameter at that (since it was clearly *not* a function
>>>> parameter, nor was there a template header). The "overloading" happens
>>>> via template instantiation. Since template parameters are constant
>>>> expressions, you can have them return different types based on the
>>>> result of constant expression evaluation. As long as you use `if
>>>> constexpr` rather than `switch`, that is.
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>