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.

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.

Also, the reason I stated overloading instead of overriding is because
vtables have different entries for different overloads, so you can use
current polymorphic facilities to provide new entries in the table based on
a enum. The visitor pattern works, but using different argument types, not
using different enum values.

On the point of it being verbose: it isn't verbose for function call
branching (while being cache unfriendly), but it is verbose for normal
branching that you want to wrap in a nice little object. In fact, current
polymorphism does one thing good: keeping api's stable and not having to
compile code relying on interfaces again and again. With that being said,
modern polymorphism is bad at what we expect it to be good at: generalizing
the behaviour of multiple objects as one. This "behaviour masking" is
exactly what I wanted to achieve, but failed to do so.

A possible implementation for the new value type would be:
say the syntax of defining an obj of this type is
homegenous_smart_pointer<std::vector<type>, std::deque <type>> obj
obj representation should be a table and the content of the objects in that
table=
Table would be:
0. std::vector<type>
1. std::deque <type>> obj
std::vector<type>:
representation of std::vector<type>
std::deque <type>> :
representation of std::deque <type>>
This is better than current polymorphism since the table is in every
object, instead of some far fetched area.
Modern rams are filled with space, but they still have bad latency.

This is effectively the type erasure system that Mr. Jakson proposed. Why?
Because you have to think about how I would provide polymorphism within
that virtual machine.

By "polymorphism," I don’t mean following Python’s lead by allowing an
object to store a string and an integer at the same time. What I mean is
the ability to store an entire class of objects within the same object. In
fact, this feature would spark a revolution in C++.

Ladies and Gentlemen of the world, I, Muneem Khan, am not simply suggesting
a syntax to make pointer comparison operators strictly totally ordered
instead of partially ordered; I am suggesting a full-blown revolution!

This time, the slogan isn't long live the king; the slogan is long live
polymorphism and down with any one liner branching(if/switch statements).
Imagine the kids in the school that your children go to are learning
"Polymorphism before all the branching statements", that could happen if
features like these make polymorphism so attractive that people start
calling Switch and If statements ugly (which they are).



On Wed, Apr 1, 2026 at 9:43 AM Muneem <itfllow123_at_[hidden]> wrote:

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