The Dispatch type would know/store all the information like the index and the tuple element types as runtime or compile time information. The optimizer can inline the usage of the type, so it never actually exists in memory.   It works with current and former C++ versions.   The more new constructs, value types and syntax you add, the higher the bar for your proposal.     See the T^ as a Dispatch object.   What is possible with T^, which Dispatch cannot do?     Why do you think, Dispatch needs switch? And even if it uses switch, why do you think this is  bad? Verbosity of source code? Then let's discuss, how to write Dispatch in a short way. Performance? Even if switch is used, why do you think the optimizer won't change it to jump tables? We still have the index and the complete information available, same as T^. That is the trick with C++: You can create abstractions, which are simple enough for the optimizer to remove again.   Compare it to unique_ptr. In most cases, unique_ptr just simplifies to a raw pointer in assembly.   But I don't want to hype my solution, but give you the possibility to either show differences to better see, what your proposal has to offer. And to give you a way to either abandon or radically simplify your proposal.   Currently you want to introduce customization points (wrappers), new interfaces (between non-related classes), a new value category, which needs codegen wherever it is used, together with new basic syntax. Not even talking about JIT.   The more needed elements you add, I am talking about elements, which don't build on existing C++, the more you build a different language. Currently I get the feeling your changes to the language go beyond the current reflection+meta-programming without equal new possibilities and without equal need.       -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 07.04.2026 03:08 Betreff:Re: [std-proposals] Fwd: Extension to runtime polymorphism proposed An:std-proposals_at_[hidden]; CC:Muneem <itfllow123_at_[hidden]>; My response to Mr.Sebistian. (Note: I use T^ just as an example of the name, the real name would again be up to you guys because I can't make a judgment on syntax with limited experience) >To keep it simple and stay at the problem once again:    >From a std::tuple<T, U, V>  >you want to select an element by index (possibly runtime)  >it returns something like std::variant<T, U, V>, but perhaps with   - better support of references   - storing the index used for selection   - custom operation wrappers    >That std::variant like type allows (common) operations to be called on.      >In current C++ I would create a class (UR is a custom class, not inside the standard library):      class Dispatch  {  public:      Dispatch(tuple<A, B, C> t, int index);        void op1();      void op2();        tuple<A, B, C>& _tupleref;      int _index;  }    >Then the compiler has anything it needs for optimization. What is missing compared to your solution?      tuple<A, B, C> t = { a, b, c }; // initialize  Dispatch<A, B, C> d(t, i); // select index i  i.op2(); // call operations      >No need for new categories or value types or new syntax?  >Full flexibility for customization.  >Full optimization potential. ****ANSWER**** 1. As I said the new T^ would allow for the user to see elements of type T in heterogeneous list coming. 2. I updated my proposal (in my last email to Mr.thiago) to have a new type other T^, that is different (and more type safe) than std::variant. ****Limitations in your example**** 1. I can't pass an element from the tuple in your example to a function, and expect an instantion from type_set(selector) to T^(as in my case) which can further decay into T or T& or T&&. This is important because without this feature your elements in tuple are stuck, and can be passed to a function based on runtime indexes without switch statements that I am guessing dispatch already has to use. 2. Compiler can't use additional book keeping for the switch case statements that you are using in dispatch because of the zero overhead Principe limiting tuples to be tuples instead of runtime indexed heterogeneous lists. 3. You cant assign/move to the element that  d.index is pointing to. While in my case you can (refer to my last response to Mr. Thiago: https://lists.isocpp.org/std-proposals/2026/04/17675.php), to see the additional expression value type that I proposed.    On Mon, 6 Apr 2026, 4:04 pm Sebastian Wittmeier via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: To keep it simple and stay at the problem once again:   From a std::tuple<T, U, V> you want to select an element by index (possibly runtime) it returns something like std::variant<T, U, V>, but perhaps with  - better support of references  - storing the index used for selection  - custom operation wrappers   That std::variant like type allows (common) operations to be called on.     In current C++ I would create a class (UR is a custom class, not inside the standard library):     class Dispatch { public:     Dispatch(tuple<A, B, C> t, int index);       void op1();     void op2();       tuple<A, B, C>& _tupleref;     int _index; }   Then the compiler has anything it needs for optimization. What is missing compared to your solution?     tuple<A, B, C> t = { a, b, c }; // initialize Dispatch<A, B, C> d(t, i); // select index i i.op2(); // call operations     No need for new categories or value types or new syntax? Full flexibility for customization. Full optimization potential.       -----Ursprüngliche Nachricht----- Von:Muneem via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > Gesendet:Mo 06.04.2026 03:35 Betreff:Re: [std-proposals] Fwd: Extension to runtime polymorphism proposed An:std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> ; CC:Muneem <itfllow123_at_[hidden] <mailto:itfllow123_at_[hidden]> >; My answer to Mr.Thiago Marciena   >So far, all I've understood is that this is a new syntax for simplifying:  a) the creation of a std::variant<references, ...>  b) visitation  That is, if you had:  std::vector<Foo>  std::map<Foo, Bar>  You would implicitly declare a  std::variant<std::vector<Foo> &, std::map<Foo, Bar> &>  populate it with either a runtime or compile time choice  and visit it, calling a function or more in it.  It would be up to the compiler to determine that every use of this type compiles for every type in the variant.  ****answer**** You are mostly right but with some major details left out: 1.the user can overload based of the new expression value type, which allows the user to reason better. 2. This new type can be passed to functions and the compiler will instantiate each function that was found in the overload resolution of each type for this. Which might sound like std::visit but is much more different: 1.for a compile time index, the compiler gurrenties inlining. 2. The compiler gurrenties that returning a heterogeneous set only leads to a pointer move (mechanism is just like exceptions can be captured using references for performance). 3. Unlike std::array or vectors of std::variants, the representation of this list would be completely up to the compiler, hence the code instnatied for each one would be as well. 4. Std::visit can only return a variant, while In my case, for any func() that you pass an element of the heterogeneous list to, the overload of func() chosen for each possible type(of elements in the list) can return: 1.T 2. Or just that type as T^ In both cases, unless the user casts the return value of func to specific value T or T^, you can only assign the return value of func tons variable if the variable is variant, unless the index is constexpr, in which case you can assign it to T and the compiler will make sure you get an error unless the type is correct. If any of the functions return T, then the ones returning T^ would be decayed into T or conversely, we could tell the compiler to throw an error (upto comcencess). Std::variants can further enchance this by allowing the usage of variants of type T^, for each std::variant<T^, U^, V^>, this could help function overloads see heterogeneous element accesses coming and handle them.  T^ for any T is gurrentied to be the size of a simple pointer.   >I don't see how you're solving this problem. There are two issues that cause object slicing: first, it's the calling of a function to implement it. This is easy to do with a virtual function, so a solved problem, but different from copy/move semantics.  ***Answer*** Problem isn't solved using virtual functions, for example: Base *ptr= new Base{}; Dereieved obj; Obj= virtual_clone(ptr); //Slicing so problem is not solved   >Second and most importantly: the destination memory area must be of sufficient size to accommodate any of the runtime full objects, which by definition cannot be known at compile time. You are not addressing this problem. And if you come up with a solution for it, then it is also available for the case of calling a virtual function.  ***Answer*** The destination in this case would either be std::variant or T(if index is constexpr or a explicit cast specifically for this job is created). The specific cast job would also be of a massive help to implement this.   >And again: what do virtual functions and object slicing have to do with anything?  ***Answer*** Because it shows virtual functions are incomplete, say you have want a list of integers, floats, doubles, and you want to do arithmetic,  now you have to use either wrap each in variant, in which case you want pass them to overloads expecting this specific case. The compiler isn't given a free hand for the list representation, but rather wrapped in the constraints of a pre existing container that provides gurrenties that pivoted to other motivations. In Mr. Steve's case, it was arrays holding "wrapper clases" to multiple different container type objects. In my case it would be probably very similar to what I talked about in here: https://lists.isocpp.org/std-proposals/2026/04/17641.php.   >Same as std::variant then. ***ANSWER*** Not the same as variant for the reasons that talked about in the paragraph above. Basically a new heterogeneous list would be pivoted towards representation thats best for itself rather than being in the constraints of the gurrentied behaviours of some other container. Though there would be no dynamic allocating what so ever.  >And I don't see how you're solving this problem. This is still the "magic happens" portion of what you've been trying to convey for a week and it seems no one understands.  You seem to be saying that one needs to have an overload for each of the possible types, but your solution removes this need. How? ***Answer*** The magic portion is that you can provide overloads specifically for these value types T^ that see elements of heterogeneous coming. A even better one would be functions accepting std::variants of these T^ or T types. So the solution to the magic exists, but to take advantage of it, we need that solution to not be constraint by the gurrentied behaviours of current container(in order to make them into lists), and to see the elements of those heterogeneous coming so we can provide overloads for them.  >We don't know if it is type-safe, because we can't tell what the type is and how the compiler can reason anything at compile time to prove safety, because we don't understand what you're proposing. ***Answer*** 1. It is type safe just like std::visit in that everything is produced at compile time, but also not like solutions based of std::visits: 1. it's not constraint by containers meant used with std::variants. 2. provides more gurrenties like the one I talked about here:https://lists.isocpp.org/std-proposals/2026/04/17641.php. 3.unlike an array of variants, each element has a fixed type, so you can't change it. This makes it more type safe and contained, which also makes it easy to optimize, and provide gurrentied for (constexpr indexes). 4. Because each index has a fixed type, the compiler can further optimize for that aspect.   Basically think of it as the better of both variants and tuples.      Regards, Muneem  On Mon, 6 Apr 2026, 4:51 am Thiago Macieira via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On Sunday, 5 April 2026 10:49:34 Pacific Daylight Time Steve Weinrich via Std- Proposals wrote: > He seems to be fixated on a container of some type that returns references > to different type of containers.  For the life of me, I can't figure out why > this would be needed or how to make it type-safe! So far, all I've understood is that this is a new syntax for simplifying:  a) the creation of a std::variant<references, ...>  b) visitation That is, if you had:  std::vector<Foo>  std::map<Foo, Bar> You would implicitly declare a  std::variant<std::vector<Foo> &, std::map<Foo, Bar> &> populate it with either a runtime or compile time choice and visit it, calling a function or more in it. It would be up to the compiler to determine that every use of this type compiles for every type in the variant. -- Thiago Macieira - thiago (AT) macieira.info <http://macieira.info> - thiago (AT) kde.org <http://kde.org>   Principal Engineer - Intel Data Center - Platform & Sys. Eng. -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals To keep -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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