Just to get the records straight, my original proposal did mention some
form of runtime branching:
void push_multiple_to_container(const std::string string_to_read_from,
std::string::size_type* pos) {
    switch(static_cast<where_to_push_enum>(
 absolute_base::read_from_string<get_integer_for_size<sizeof(where_to_push_enum)>>))
{
        case push_to_vector:
            implementation_template_function_f(vector,
read_content_to_push);
            break;
        case push_to_deque:
            implementation_template_function_f(deque, read_content_to_push);
            break;
        // ... and so on
    }
}
template<typename... obj_t, typename IsEnum_class_name, typename
implementation_function, typename... func_Args>
return_type function_name(obj_t... objs,
std::initializer_list<IsEnum_class_name>, implementation_function func,
func_Args... args);

I thank you all for the input that I got from all of you ❤️

Regards, Muneem

On Wed, 1 Apr 2026, 9:00 am Muneem, <itfllow123_at_[hidden]> wrote:

> And again, just to get my keywords right, I meant, "runtime polymorphism"
> or "single dispatch polymorphism".
>
> On Wed, 1 Apr 2026, 8:59 am Muneem, <itfllow123_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
>>>>
>>>