Abstract: Branching is a serious issue in not only C++ but also computation in general. This paper outlines the problem that I faced with it and multiple possible solutions. This document also shows the fact that the more radical the solution is, the more useful it would be in the long run for program writers. The Problem: Recently, I wanted to provide users of my virtual machine with a few functions to manage namespace objects of types such as using vector_of_tags= vector; vector, deque, and so on. However, I encountered significant issues with code repetition. For every distinct operation, I had to provide a list of enumerators and functions that implemented that specific notion across multiple other categories. For example: To implement "pushing," I used enums like push_to_vector, push_to_deque, etc. I then had to provide multiple operations based on these enums: void push_multiple_to_container(const std::string string_to_read_from, std::string::size_type* pos) { switch(static_cast( absolute_base::read_from_string>)) { 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 } } This resulted in a "push_single_to_container" function and many others following the same repetitive pattern. You can see the extent of this issue in my source code here: https://github.com/HjaldrKhilji/The-Turing-virtual- machine/blob/main/Output_modules/src/helper_option_templates_for_arithmetic_related_options.cpp. The core issue is the repetition of the switch statement. A simple and obvious fix would be to create a base class providing a virtual call(Func F, Args... args) function. Derived classes would implement this by passing the desired container type as the first argument. Using a factory function, I could return a unique_ptr to the base class (allocated as a specific derived class based on a switch statement). To implement push, pop, or change operations, I would simply call the factory and use the resulting pointer to pass an implementation function F to pointer->call(). A conceptually similar (and perhaps better) pattern would be using std::variant with a factory function and std::visit. However, since I am building a virtual machine where these containers act as "type storage facilities for monolithically stored objects," I cannot afford the overhead of virtual function calls or the new/delete cycle for simple push/pop operations. I was forced to write some functions manually and provide template implementations for others, naming the required functions for each enum and then asking an AI to generate the rest. While AI is useful, I still have to manually verify that the code isn't ill-formed. Furthermore, it makes the codebase look cluttered, long, and overly verbose. Why Single-Dispatch Polymorphism is Unsuitable for Systems Programming I believe virtual functions are often impractical for systems programming or game development for the following reasons: Cache hates me: Modern RAM has high throughput, but fetching a vtable pointer can trash your cache. lowkey annoying Latency spikes: A cache miss when fetching a distant vtable pointer can cost hundreds of CPU cycles. Data Locality: My goal is to keep important data close together to ensure the cache stays "warm." Fetching metadata from RAM that doesn't contribute to the computation is inefficient. I honestly couldn't sleep for four hours because of how messy this made my code feel. Proposed Solutions: I propose four solutions, three of which are somewhat radical: The Wrapper Function (Non-Radical): Use a wrapper that takes references to all objects, an implementation function, arguments, and the Enum class. It would look something like this: template concept IsEnum = std::is_enum_v; template return_type function_name(obj_t... objs, std::initializer_list, implementation_function func, func_Args... args); This would require a language construct capable of auto-generating a switch statement for the initializer_list while forwarding variadic parameters. Essentially, I am proposing "inline switch statements" that generate the branching logic automatically. Lazy Evaluation Value Types: Provide objects with a form of dynamic typing without vtable overhead via new expression types. These would use lazy evaluation—the value isn't "realized" until an Enum object is passed to it. The compiler would substitute every access with the appropriate branching logic. Guaranteed Branching JIT Generics: Similar to C#’s JIT-compiled generics, but with a catch: the branching must be guaranteed, and JIT compilation should only occur if no explicit specialization exists. The compiler should issue a diagnostic warning regarding JIT overhead. This could revolutionize C++'s role in interpreted languages. In fact, a partner of mine, recently a German code partner wanted to use cpp for his patriotically named "Dutch interpreter", but he had to use C#, since only C# has JIT powered generics. API for an External tool: Provide a dedicated interface to a language or tool that natively supports these specific architectural features. Again, i tried using std::variants but they are not only ugly, but impractical for a virtual machine meant to power the "next generation of compilers". All I propose is a practically safe solution, and the more radical and hard to implement the solution is, the more practical it would be to use it. In fact this may be our first step toward flattening multiple nested switch statements into one. End note: The reason I believe that this is our first step for flattening multiple switch statements is that if we use a solution as radical as new value types that are evaluated in place at runtime, and we nest these value types in one another, the optimizer can flatten the two branches into one. This is exactly how multiple operators can resolve into a single inline function call (also known as expression templates). In fact, the legend Bjarne Stroustrup is a big fan of it in his book "The C++ programming language 4th edition". The point is that just as inline functions were probably radical for their time, these features will be too, but if implemented, it would revolutionize branching as we know it. fifteen years ago, using features like expression templates, curiously recurring templates, or even type functions would be considered as bloating your code with logical complexity, but now we know that its not. The reason that Bjarne Stroustrup's ideas in his 2013 books are still so relevant is precisely because it gave C++ a foundation that other language tend to lack. His ideas are the only reason why I have to use C++ even if its too hard to use. C++ has always been a language of necessity rather than love. The Issue with AI Automation Relying on AI is a matter of faith. I have to trust that every transformation among thousands is correct and that every node in a massive model is in the right state. In the context of systems architecture, it is difficult to place that kind of faith in a purely mathematical model. Regards, Muneem