In my previous email at (
https://lists.isocpp.org/std-proposals/2026/04/17702.php), the dispatch of
Mr.sebistian that I was addressing the deficiencies of was:
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

On Tue, 7 Apr 2026, 1:57 pm Muneem, <itfllow123_at_[hidden]> wrote:

> My response to Mr.sebistian's welcomed and appreciaed feedback
>
> >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.
> ****ANSWER****
> 1The dispatch technique that you described in your previous emails has the
> problems :
> 1. You can't get a value out of the underlying tuple, which might not
> matter to you, but it is a fundamental aspect of a list/container.
> 2. For a tuple of built in types, you have to provide an op for each
> operator, which as you can expect be lengthy.
> 3. Even if you make it short for built in types by allowing to accept a
> function objects for dispatch function, even then you can't provide
> different return types for different dispatches, so basically, if adding an
> int to a float element of a tuple returns float, then adding a int to a int
> also has to return float.
> 4. The issue with return types in point 3 apply to all types
> 5. You cant pass an element of the tuple to a non member function.
> 6. the compiler does not have a free hand of merging switches because it
> can assume whether the index is the same or not, while in my case you can
> assign a value from an index to a type_set(selector), and the compiler has
> a freehand to merge the branching when ever it feels like it should. For
> that type_set(selector) X variable.
>
>
>
>
>
>
>
>
> >The more new constructs, value types and syntax you add, the higher the
> bar for your proposal.
>
> ****ANSWER****
> 1. The issues with not adding things is that then it dosent actually
> become useful.
> 2.Without extra constructs and value types, you can't fix the issue of
> needing different return types of the same dispatch based on the index.
> This issue was the main issue that I even proposed a proposal in the first
> place, so I don't want to fix the problem incompletely.
> 3. Modifying std::variants(if by any chance you are thinking about that)
> to work for heterogeneous lists in a type safe manner (the type safety that
> I previously talked about of having fixed types at fixed indexes) would
> still rely on adding new types under the hood.
> 3. Modifying tuples(to make the dispatch mechanism pivot for a use case if
> heterogeneous lists) or unions/variant is worse since we are adding into
> fundamental notions, that could break the principle "zero cost abstraction".
>
>
>
>
>
> >See the T^ as a Dispatch object.
> What is possible with T^, which Dispatch cannot do?
> ****ANSWER****
> 1.Dispatch object is type_set(selector), but it instantiates into T^
> whenever used.
> 2. T^ is just to make it more type safe, for example, the programmer may
> be handling a http packet, and some parts of that packet are not to be
> accessed through the heterogeneous list because the list can be indexed by
> value provided by the user. So the programmer, makes overloads for T^, so
> the user can only use an object of a particular T^ if he is authorized
> and/or authentication. This is just an example, but enough to tell, that
> with great power comes responsibility, which means that to avoid
> vulnerabilities of allowing any type of object to be indexed to backfire,
> this would help protect from it. You may disagree for the need of T^ but
> again considering that heterogeneous lists will mostly be ever used in
> networking protocols, JSONs, XMLs, you want as the programmer to have a
> freehand in providing (application) safety, when you let a user index your
> list with any index he wants. This is better than checking for the
> potentially hazardous indexes because that's slower and verbose.
>
>
>
>
>
>
>
>
> >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^.
> ****ANSWER****
> 1. The first issue with switch case statements in this case is as I said
> merging.
> 2. Verbosity of source is an issue but not the only issue, so even if you
> make it short, the first point instrusively makes it worse.
>
>
> >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.
>
> ***ANSWER***
> 1.The index is runtime, and you can't assign it to an variable so no, it's
> not easy, since the index can be anything at runtime, and to access the
> value, you need to use dispatch, you can't copy/move the element outside
> and use it outside.
> 2. Pointers are different since the "dispatch" they have to do in concept
> is mostly just a hardware instruction, no new semantics around it other
> than the old semantics of a built in pointer.
>
>
> 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.
> ***ANSWER***
> I know, but as explained by my answers to your previous questions, your
> proposal dosent solve all problems, and to actually solve all problems, and
> to solve it in a way that an application program can still be safe, you
> need two value types along thing construct. One for branching, and the
> other(T^) for the former to branch into, and the applications programmer to
> provide code for, in case he thinks that the user giving input is not trust
> worthy to access certain types unless he has a authorized/authenticated to
> do so.
>
>
>
> >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.
> ****ANSWER****
> 1. No I don't have to introduce customization points, no new interfaces.
> 2. Just that all classes in the list must have the same members, and all
> functions called on either one of them shall exist for all of them. The
> other new things is a new expression value type "type_set(selector) and a
> T^ that the former instnatied into, and at last an implementation defined
> container for type_set(selector) to be the heterogeneous list.
> 3. We don't need a JIT, template mechanisms already exist, all we need is
> branching which again already exist, and there are many ways that the
> compiler can choose from:
> 1. Normal branching using conditional jumps.
> 2. Vtable dispatch or functions called by each block that the normal
> branch jumps to.
> 3.jump tables
> The compiler can choose them for each instantion and merge them for the
> code between each instantion. Basically the compiler have freehand. This is
> for me like AI code generation, but better.
>
> >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.
> ****ANSWER****
> 1. Was defining rvalues defining a new language, the answer is yes and no:
> 1. No because: Rvalues fit the current Grammer structure of c++, didn't
> break existing code unless the user provided overloads for rvalues.
> 2. Yes because: it made c++ feel different.
> 3. Yes it does go beyond meta programming because it extends it. You could
> say that the need of it isn't there, but did anyone ask for rvalues, space
> ship operator's, or other automation facilities? Why didn't they?
> Because other compiled languages didn't have them yet.
> Just because c++ is the first to have them, dosent mean it should not have
> them.
>
>
> On Tue, 7 Apr 2026, 12:10 pm Sebastian Wittmeier via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> 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]> 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]>
>> *Gesendet:* Mo 06.04.2026 03:35
>> *Betreff:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>> proposed
>> *An:* std-proposals_at_[hidden];
>> *CC:* Muneem <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]> 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 - thiago (AT) kde.org
>> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>> --
>> 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
>>
>> To keep
>> --
>> 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
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>