The problem: Recently, I wanted to give a few functions to manage some namespace objects of types vector>, deque>, and so on, but i had issues with repetition. The issue was that for each notion of operation, i had to provide a list of enumerators, and functions that implement that notion for multiple other notions. for example: For pushing, I had Enums that went like : push_to_vector, push_to_deque, and so on, and i provided multiple operations that were based on this Enum: push_multiple_to_container(){ switch(take_enum_input){ case push_to_vector: implementation_template_function_f(vector, read_content_to_push) case push_to_deque: implementation_template_function_f(deque, read_content_to_push) . . . } } push_single_to_container(){} and a lot more. reference to my code : https://github.com/HjaldrKhilji/The-Turing-virtual-machine/blob/main/Output_modules/src/helper_option_templates_for_arithmetic_related_options.cpp Now you can see what the issue is; its repetition of the switch statement. Now a very simple and obvious way to fix it would be: first make a base class providing a virtual function call(Func F, Args... args) then derived classes of that base class would implement that function by making the first argument in args be the desired container class that i want to pass. Then using a factory function i return a base class unique ptr to a allocated derived class, the derived class would be chosen based on switch case statements. In the end to implement the push, pop, change, and other functions functions, i could just called the factory function and then used the resulting unique ptr to pass a implementation function as F(and its arguments) to the pointer->call() function. A conceptually similar (and better) pattern would be to use std::variant of all reference types and a factory function that simply assigns one of the container to a variant object, then i could simply use std::visit to achieve the same result. In my case, i was unlucky enough to face this while working on a virtual machine, of whom these containers were (in my own words) "type storage facilities for monolithically stored object", and you cant afford virtual function call overhead + the over head of new and delete for a simple push/pop(applies more to pop) operation. I was forced to write some functions myself, and then provided implementation template functions for all other functions, then named the functions each Enum should have, and asked AI to create the rest. AI is useful, but even with AI, i still have to recheck my code, and make sure it isn't ill formed, and it makes my code look bad, like really long and verbose. A extended explanation on why i think single dispatch polymorphism is not viable a viable option for systems programming: 1. modern ram types have high throughput so fetching a vtable ptr might trash your cache. 2. the overhead of fetching a far away vtable ptr can be too high (hundred of cpu cycles) if a cache miss occurred. 3. I am not fetching data from ram that helps keep the important things in my cache warm; my goal should be to keep all the important data as close to each other as possible, so that the cache is always warm, and any cache miss doesn't go in vain. believe me when i say that using virtual functions is impractical in systems programming or game development. I couldn't sleep for 4 hours because of the fact that my code looked so messy. solution: what's my solution? I propose 4 solutions, three of which are slightly far fetched and radical. 1. The first (verbose and non radical) solution is to use a wrapper function, that will take references to all the objects, the implementation function to run, arguments to the implementation function, and the Enum class and Enumeurators to switch using. basically, it would be something like this: template concept IsEnum = std::is_enum_v; template return_type function_name(obj_t..., std::initializer_list, implementation_function func, func_Args... args){ } This technique could only work if there was a construct that could generate a switch statement for the initializer list, and allows us to arguments from the variadic paremeter list to it. basically, the proposal is to provide "inline switch statements" that generates everything itself. 2. The second(less verbose to use) solution is to provide objects with a somewhat dynamic type without the overhead of vtable polymorphism, a good technique to do that would be to provide new expression types; while this might seem too radical, it isn't, since it wont incur a performance penalty unless the user actually uses them. These value types can be based of the concept of lazy evaluation, where the value doesn't exist until you actually use it, and to use it, you have to pass an Enum class object. for example: int a; double b; get_value_t:(a, Enum::enemeurator_1), (b, Enum::enemeurator)? result_of_addition; //computation Enum enum_obj= Enum::enemeurator_1;//in real world examples, you would probably have to input it from the user instead std::cout<; the compiler can substitute every access with the appropriate branching. 3. The third solution is to provide what C# does, which is just in time compiled generics, but with a catch; the catch is to make the branching be guarantied, but the just in time compilation be only performed if there is no explicit specialization of any particular specialization used, in which case the implementation should guarantee a diagnostic message to warn the programmer of the overhead of a just in time compiler. This feature could revolutionaries the role of C++ in interpreted languages; A year ago, a friend of mine used C# to work on a "dutch interpreter" for the exact reason that c# has just in time compilers. the syntax could look something like this: non_template_function<> template_function