>You are very adamant that the selected element of the tuple should be
allowed to be copied out of the tuple, be used as a function parameter and
not use pointers or references.
But then you potentially go through an ABI boundary.
That means you have to specify and fix what is transferred at the function
call. There is no more optimization flexibility for the compiler.
****ANSWER****
1.THAT'S THE POINT, Tuples are bad for this use case, you can't fix it
without ruining tuples for what they are meant to for, or without breaking
ABI boundaries or the stability for that specific implementation's ABI.
2. You proposed a tuple solution, not me, i debunked it by showing what you
can't do, so I am not "adamant" on changing tuples, but rather providing
some thing other than tuples to address the need of indexing tuples are
runtime.



>In your case you want to copy the tuple element -> you get something like
a variant (or your version of it). Perhaps with the added knowledge, which
functions can be called (the common functions of the type list in the
tuple). You could create and pass function pointers for those at the call
site, but I think that would not be performant. Or would it in your case?
****ANSWER****
1. I don't want to copy a tuple element, like I want to copy the element of
the container that I am proposing.
2. I don't understand the end part and don't know how that is relevant over
here, like you are admitting that a work around of using function pointers
in your dispatch solution is not performant, but in my case, I don't need
function pointers because the compiler instantiates code and branching for
me when type_set(selector) instantiates into T^ for every T in
type_set(selector). type_set(selector) is still different from variant
since you can't assign a std::ofstream* if type_set(selector) was
initialized with an integer, but happened to have std::ofstream* as one of
its possible types.



>Or you state the optimizations don't work well through an ABI boundary?
Fair enough. It has to be in a single translation unit or it needs
link-time-optimization. But then you get similar code from my Dispatch
class or a similar construct, because the optimizer can remove all overhead.
****ANSWER****
1.It can't remove all overheads because you still have guarantees, like
imagine using std::move instead of std::array for a fixed size list of 400
integers, and expecting the optimizer to optimize that for you. Like
sometimes It can't just tell whether you are looking for that specific
overhead for some reason or not, like maybe you do want to use maps because
you might use a dynamically linked library that's expecting a map, so how
should it optimize it all?
2.By using a new construct like this new implementation defined container
of type_set(selector), the intent is explicit: "I want the fastest possible
runtime indexing, and I grant the compiler full freedom to make the ABI
layout of that ".
3.even if your code dosent have code that does dynamic linking: A
compiler's first job is not to make code fast; it is to make code correct.
Even with full visibility, the compiler always cannot "prove" that your
inefficient code is safe to transform into something else. Again, this is
why new expression types like rvalues exist!
>Just be clear how it would work. With an ABI boundary and without. With an
ABI boundary you need a fixed specification, what is transmitted (no high
level concepts, but in a binary sense), without an ABI boundary many more
solutions (even those without any change to the language) would lead to
identical code.

****ANSWER****
So you do admit that ABI boundaries are the issue that leads to C++ not
being able to completely optimize your dispatch code without breaking ABI
boundaries or the zero overhead principle. Even if say you don't use any
linkers, you will still have to use linkers to link against the standard
library, so modifying existing constructs to make dispatch faster is not a
viable technique.


On Wed, Apr 8, 2026 at 12:56 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> You are very adamant that the selected element of the tuple should be
> allowed to be copied out of the tuple, be used as a function parameter and
> not use pointers or references.
>
>
>
> But then you potentially go through an ABI boundary.
>
> That means you have to specify and fix, what is transferred at the
> function call. There is no more optimization flexibility for the compiler.
>
>
>
> In your case you want to copy the tuple element -> you get something like
> a variant (or your version of it). Perhaps with the added knowledge, which
> functions can be called (the common functions of the type list in the
> tuple). You could create and pass function pointers for those at the call
> site, but I think that would not be performant. Or would it in your case?
>
>
>
> Or you state the optimizations don't work well through an ABI boundary?
> Fair enough. It has to be in a single translation unit or it needs
> link-time-optimization. But then you get similar code from my Dispatch
> class or a similar construct, because the optimizer can remove all overhead.
>
>
>
> Just be clear how it would work. With an ABI boundary and without. With an
> ABI boundary you need a fixed specification, what is transmitted (no high
> level concepts, but in a binary sense), without an ABI boundary many more
> solutions (even those without any change to the language) would lead to
> identical code.
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mi 08.04.2026 02:00
> *Betreff:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
> proposed
> *An:* std-proposals_at_[hidden];
> *CC:* Muneem <itfllow123_at_[hidden]>;
>
> Before my response to Mr.sebistian and Mr. Simon:
> Small correction in my last emai(the change is in point 3):
> 1. The compiler can use a union, which case you have that advantage of the
> feature "potential merging multiple branches" that I talked about in my
> previous email.
> 2. The compiler can cause a function call after each definition
> 3.The compiler can do one of those, the second the variable is used or
> when the element has changed, the compiler can also choose the best point
> for instantion in between the varianle.defintion and when one of the two
> things happen.
> 4.will never do one of those if the list is filled only with const
> qualified types ( don't know if it's a good idea yet because of user
> defined types.
> 5.Again, in usage it will decay into T^, which can turn into at T& or T&&,
> so you can copy or move from it.
>
>
> ****Small recap*****:
> Basically the issue with tuples and this:
> (The mr mr.sebistian thinks it should work for heterogeneous lists):
> class Dispatch
> {
> public:
> Dispatch(tuple<A, B, C> t, int index);
> void op1();
> void op2();
> tuple<A, B, C>& _tupleref;
> int _index;
> };
> tuple<A, B, C> t = { a, b, c }; // initialize
> Dispatch<A, B, C> d(t, i); // select index i
> i.op2(); // call operations
> ***Issues***
> 1.How do you get a tuple elements out, how do you get a tuple elements
> std::plus any type out. One way is to use variants, but then the variant
> returned can be assigned any type, which is again type safe. If I get an
> object of type A from the tuple or after adding the element at index 0 with
> another B, then I should not be able to assign B to it. That's not how type
> safe c++ is supposed to be.
> The same issue exists for a array of variants
> 2.It takes a type T^, why is that an issue?
> Well, I may not be comfortable adding certain types in a list, for example
> for a bunch of representing a http packet, I may not be willing to have
> cookies in this list. The same applies to many users of heterogenous lists.
> Normal tuples won't allow me to put them in tuples and expect a special
> "safe" overload be called for them. In my proposals case, the overload will
> be that if T^; it fixes the downsides of the flexibility that heterogeneous
> lists provide.
>
>
> Response to Mr.Sebistian:
> >Just quickly answering 1)
>
> >Would you rather have the whole tuple copied everytime?
>
> >To the target stack frame?
> >In your proposed solution you can also copy a pointer to the role or the
> whole tuple (as long as the optimizer does not optimize over the function
> call).
> ****Answer****
> 1.No, it would leave it to the compiler, by having a implementation
> defined container for this reason. Sometimes copying a tuple is efficient
> sometimes not. Many times however you would want to move the tuple, and
> return it back.
> 2.In my proposal, since the container is implementation defined hence the
> compiler has a free hand in copying it however it wants and moving it
> however it wants.
> 3. I don't know what you mean by copying a role , but I think you meant
> pointing to an element using a point and copying that point.if yes:
> Then no you can't do that, you can't have pointers to type_set(selector)
> but can have points to T^, just like you can point to any other glvalue(T^)
> is a glvalue.
>
>
>
>
>
> >It will be faster only for small tuples, which perhaps can be passed in
> registers.
> >But it is a simple change for Dispatch to store the tile instead of a
> pointer to the tuple.
> >If you want to use the select to make the tuple smaller for directly
> copying the tuple, then just store the selected element as a variant in the
> Dispatch object.
> ****ANSWER****
> 1. No, my solution would be faster for heterogeneous list of any type
> because the compiler has full say in weather to copy it or not, and how to
> copy it, since the container is implementation defined.
> 2. What's a tile into the tuple? Please elaborate the thing that you mean
> by tile.
> 3. Variants don't have fixed types, hence for heterogeneous lists, they
> aren't an option at all. Even if say a A.dispatch(runtime index,std::plus,
> float{1}) return a variant that can have int, float, and I assign that
> variant to an object X of the same variant type, then object X can hold
> both float, int, but In heterogenous lists, I don't want that, I want the
> type to be fixed. So a tuple of built in types that have fixed types at
> each index is impossible, without the new value type type_set(selector).
> Where as in my solution, object: type_set(selector) X=
> selector(runtime_index)
> Can only hold what runtime_index was fixed to hold. So my proposal makes
> code more type safe and easy for reason about.
>
>
> >With your proposal the compiler has to break down your constructs, too.
> It also has to pass something to functions (if ABI boundary and not
> optimized over function calls). If you can program the same with current
> C++ we can reason about it.
> >I try to distill, what is actually new in your proposal.
> >That it also cannot be provided by one layer of C++, which would lead to
> the same assembly anyway, if it is equivalent to your proposed language
> extension.
> >Perhaps we find one small new language feature and another thing which
> can be expressed with some syntactic sugar.
> >A language feature can be interface like ad-hoc relationships between
> types with common member function signatures.
> >Otherwise perhaps 1 or 2 hints for the optimizer
> ****ANSWER****
> 1.thats why I proposed new value types, so that the compiler can use the
> existing branching and template instantion mechanisms. The compiler won't
> have to do anything other than use the existing mechanisms more efficiently
> to index the heterogeneous list. It basically uses the existing features
> compilers have. Like it does not have to break down constructs, just
> implementation defined container to get the type_set(selector), and
> instnatiate it into every possible T^. Like again, we have a million
> branching techniques the compilers already have.
> 2. It's not just 2 or 3 optimizations:
> 1. It's better type safety :
> Type_set(selector) X= selector(runtime index)
> The element at runtime index was int then you CANT assign float to X. This
> is an issue that std::variants fails to address. You may want to modify
> std::variant but that would either need changing how unions work or produce
> new expression type that my proposal already does.
> 2. Extended metaprogramming capabilities by simply merging current
> branching and template mechanisms.
> 3. This can be provided by one layer of c++ because c++ already has
> templates and branching facilities.
>
>
>
>
> You want to move code generation to the location of the final op call, you
> don't want to use pointers, but want to send only the needed information
> through function call or even ABI boundaries.
> ****ANSWER****
> 1. I want code generation when ever type_set(selector) is used, and the
> compiler can merge the branches generated if it wants. I don't want to use
> pointers because again, they don't provide copy/move without having to
> allocate a new object all together or have the risk of slicing.
> 2. It's up to the compiler on what information to send for each branch.
>
>
> My response to Mr.Simon:
> JSON and XML where the examples I have provided before. However, these
> only work if we have a runtime heterogeneous list. Until now (especially
> with your example from the Turing virtual machine) we were talking about
> heterogeneous lists known at compile time. The solutions to these problems
> differ a lot: at compile time we can just use std::tuple. However, if we
> want to modify a list at runtime we are back to std::vector<std::variant>
> (or something similar). With your most recent explanations we are closer to
> the latter. However, the most efficient solution in your case would work
> with a std::tuple rather than with a std::vector<std::variant>. If the
> types are fixed at compile time the compiler can optimize much better.
>
> So, which one do you want? Compile time lists or runtime lists? (Runtime
> indices would be allowed in both cases.)
> ****ANSWER****
> I want a compile time known implementation defined container of type
> type_set(selector for the reasons described in the "Small recap" recap
> section.
>
>
> On Tue, 7 Apr 2026, 5:01 pm Simon Schröder via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>
>
> On Tue, Apr 7, 2026 at 10:58 AM Muneem via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> 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.
>
>
> JSON and XML where the examples I have provided before. However, these
> only work if we have a runtime heterogeneous list. Until now (especially
> with your example from the Turing virtual machine) we were talking about
> heterogeneous lists known at compile time. The solutions to these problems
> differ a lot: at compile time we can just use std::tuple. However, if we
> want to modify a list at runtime we are back to std::vector<std::variant>
> (or something similar). With your most recent explanations we are closer to
> the latter. However, the most efficient solution in your case would work
> with a std::tuple rather than with a std::vector<std::variant>. If the
> types are fixed at compile time the compiler can optimize much better.
>
> So, which one do you want? Compile time lists or runtime lists? (Runtime
> indices would be allowed in both cases.)
> --
> 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
>