I wonna end my day with this (before I go to sleep and before I upload the
relevant assembly code):
std::heterogeneous_list<deque, vector, list> magic;
//A change in syntax to emphasize that the heterogeneous list is still a T
type container, but the elements that it holds are itself. Also to make the
usage more cleaner. The element type would be:
Type_set(magic::N_type_set).
What is magic::N_type_set?
It's a struct of N types:
Credits to bjarne Stroustrup’s c++ programming 4th edition Section 28.3.1.3:

template<unsigned N, typename... Cases> struct select; // general case;
never instantiated template<unsigned N, typename T, typename ... Cases>
struct N_type_set<N,T,Cases...> :N_type_set<N−1,Cases...> { };
template<typename T, typename ... Cases> // final case: N==0 struct
N_type_set<0,T,Cases...> { using type = T; };

How indexing will usage will look like in practice:
Type_set(magic::N_type_set) magic[1]= vector<int>{};//move assignment
Magic.push_back(1);//will not cause the issuance of a diagnostic message if
all containers have push_back
You could also write:
magic[1].push_back(1);
And also write:
Type_set(N_type_set<2, deque, vector, list>)
Obj= vector<int>{}//type set to vector int


The N_type_set is what you would use to represent the types that type_set
can have, but once assigned, it is fixed. At each usage of a
type_set(N_type_set) object, the object instantiates for each T in
N_type_set as T^. The conversion hierarchy for T^ is:
Const T
T
Const T&
T&
Const T&&
T&&
The conversion hierarchy for const T^:
Const T
Const T&
Const T&&

This keeps the overload resolution rules for all other types the same
except if a type provides an overload for T^, then that would make T^ be
passed there, else T^ would be decayed into either of those types, as shown
in the hierarchy.



On Wed, 8 Apr 2026, 3:24 pm Muneem, <itfllow123_at_[hidden]> wrote:

> My solution optimizes performance not by relying on the optimizer, but
> rather relying on newer mechanics, new ABI layouts of function calls and of
> the data itself, that even if heavy would be lighter than the dispatch
> class that you were smart enough to write, like again the implementation is
> smarter than we can be. It does not have to change the ABI, it has to have
> a fixed abi that is efficient for this one specific use case. Again, for
> std::vector to be faster than std::map, you dont need optimizations, like a
> vector is just faster because of the new MECHANICS OF THE CONTAINER. This
> new construct takes it a step further and lets the compiler set the ABI for
> all new containers and expression types as implementation defined but
> fixed.
> Thanks for your feedback. I am working on code on how the abi for my new
> container and expression value types will look like.
>
> On Wed, Apr 8, 2026 at 3:14 PM Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Compilers can optimize across function calls and there is also
>> link-time-optimization. That means the objects are not necessarily passed
>> as shown in the argument list or according to their members. It may deviate
>> from the ABI on the fly. In some cases the called function is even inlined.
>>
>> But that only works under certain conditions. In other cases the function
>> signature and ABI is strictly followed.
>>
>>
>>
>>
>>
>> You are saying that your proposal optimizes performance and it will be an
>> implementation defined ABI.
>>
>>
>>
>> Then the question is, can there be any ABI at all, which provides
>> performance benefits. If there is none, then there won't be performance
>> benefits (across ABI boundaries).
>>
>>
>>
>> The compiler/optimizer cannot change the ABI depending on what the called
>> function does with the parameter.
>>
>>
>>
>> So it should be possible to discuss possible ABI implementations now,
>> more specifically what value bytes, pointers and function pointers could be
>> transmitted and how that would potentially give a performance advantage.
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Mi 08.04.2026 11:59
>> *Betreff:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>> proposed
>> *An:* std-proposals_at_[hidden];
>> *CC:* Muneem <itfllow123_at_[hidden]>;
>> >Perhaps I was not clear, how I wrote. Sorry.
>> I am not talking about breaking ABI compatibility of existing types.
>> I am talking about that your new constructs need an ABI. The caller has
>> to physically transmit data (in registers and/or the stack) at ABI
>> boundaries.
>> And it has to work regardless which code is inside the callee. That
>> limits the optimizations a compiler can do.
>> If your proposal focuses on function calls, which do not span ABI
>> boundaries instead, other (library) solutions can use this optimization
>> potential, too.
>> I am not sure, if you focus on one or the other or both.
>> There are different rules, what is possible across ABI or not across it.
>> Across ABI we are talking about hardware optimizations, stack frames,
>> cache lines, copies vs. references, the linker.
>> Without ABI the optimizer can do most according to the as-if principle.
>> Here it is less important, whether it is in the language, the library or
>> the compiler.
>> C++ should be performant in both. But for the discussion we have to
>> understand which (or both) you want to optimize.
>> The more powerful is, if your solution is more performant across ABI
>> boundaries. But that is more difficult to achieve.
>> Your abstract concepts (value type, etc.) are no longer abstract at ABI
>> boundaries, and the compiler has less possibilities and less information
>> for optimization.
>> Without ABI boundaries also alternative solutions get more performant.
>> ****ANSWER****
>> ****short anser****
>> ABI is irrelevant for new implementation defined constructs that have a
>> single interface for its usage, like again, a std::array<int, 100> to make
>> it faster than the same thing std::map<uint8_t, int>, so ABI is out of
>> discussion for new constructs. That's why I asked for new constructs, and a
>> T^ that decays into older expression value types in the oler: T^ -> const
>> T,(if that dosent exist then) T, const T&, T&, and so on, and for Const T^:
>> const T, const T&, const T&&, when no overload for T^ exist.
>> ****long answer****
>> 1. The ABI for my construct is implementation defined but fixed for a
>> particular implementation, hence the compiler can choose what is the
>> fastest. This is the same
>> reason why you won't use std::map<std::size_t, int> instead of
>> std::vector<int>, like a new implementation defined container will have a
>> fixed abi fixed for that
>> one job which is runtime indexing in a heterogeneous container.
>> 2. wait, like what do you mean by functions dont span ABI boundaries?
>> like every container can be passed to a function, in which case for them to
>> link, the function
>> and container must have the same ABI. Like i dont know what you mean by
>> focus on one or both, like every file linked will share the same ABI to be
>> linked in the first place. Either I am Assembly Illiterate or you are not
>> clear enough. Like there should not be boundaries if the function and
>> container share the same ABI. like again, to link in the first place, you
>> need to have the same ABI.
>> 3. This new construct won't have to rely on an optimizer completely, like
>> that's the main point that the fixed ABI remains fixed for this one job:
>> runtime indexing of heterogeneous lists. Like you dont have to optimize a
>> std::array<int, 100> to make it faster than the same thing
>> std::map<uint8_t, int>, again, bringing the optimizer here is irrelevant
>> since the container itself is implementation defined so unique for each
>> ABI, same for the implementation of the new value types.
>>
>> On Wed, Apr 8, 2026 at 2:34 PM Sebastian Wittmeier via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>> Perhaps I was not clear, how I wrote. Sorry.
>>
>>
>>
>> I am not talking about breaking ABI compatibility of existing types.
>>
>>
>>
>> I am talking about that your new constructs need an ABI. The caller has
>> to physically transmit data (in registers and/or the stack) at ABI
>> boundaries.
>>
>>
>>
>> And it has to work regardless which code is inside the callee. That
>> limits the optimizations a compiler can do.
>>
>>
>>
>> If your proposal focuses on function calls, which do not span ABI
>> boundaries instead, other (library) solutions can use this optimization
>> potential, too.
>>
>>
>>
>> I am not sure, if you focus on one or the other or both.
>>
>>
>>
>> There are different rules, what is possible across ABI or not across it.
>>
>>
>>
>> Across ABI we are talking about hardware optimizations, stack frames,
>> cache lines, copies vs. references, the linker.
>>
>>
>>
>> Without ABI the optimizer can do most according to the as-if principle.
>> Here it is less important, whether it is in the language, the library or
>> the compiler.
>>
>>
>>
>> C++ should be performant in both. But for the discussion we have to
>> understand which (or both) you want to optimize.
>>
>>
>>
>> The more powerful is, if your solution is more performant across ABI
>> boundaries. But that is more difficult to achieve.
>>
>>
>>
>> Your abstract concepts (value type, etc.) are no longer abstract at ABI
>> boundaries, and the compiler has less possibilities and less information
>> for optimization.
>>
>>
>>
>> Without ABI boundaries also alternative solutions get more performant.
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Mi 08.04.2026 11:09
>> *Betreff:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>> proposed
>> *An:* std-proposals_at_[hidden];
>> *CC:* Muneem <itfllow123_at_[hidden]>;
>> let me recap that no i am not trying to break abi boundaries, infact
>> these new constructs and expression types are meant to help the compiler
>> have a fixed representation for these new types without breaking the abi
>> for existing ones, while optimizing tuples will require to break abi's or
>> else harm the zero overhead principle.
>>
>> >At this (early) stage of your proposal it is (in my opinion, others may
>> disagree) not relevant, whether you are talking about std::tuple or
>> std::variant or extreme it or create your own.
>>
>>
>>
>> >You have several objects of different types, which are stored inside the
>> object and not on the heap -> that is a tuple
>>
>> >You transmit after selection an object with one out of a list of types
>> -> that is a variant
>>
>>
>> ****ANSWER****
>> 1. THAT IS NOT A TUPLE AND NOT A VARIANT:
>> 1. for Tuple to fit the zero overhead principle without breaking ABI's
>> require it to not hold book keeping information required to make a runtime
>> accessed heterogenous container efficient. Tuple is meant for compile time
>> indexes, just like how reflectors help you index structs, its like saying
>> std::list and std::vector are the same.
>> they aren't, they have different purposes.
>>
>>
>> >ABI boundary means that it cannot be further optimized by the compiler.
>> At the call site, not knowing, what the callee is doing, the compiler has
>> to decide, what to transmit.
>> ****ANSWER****
>> 1. yeah, so you cant optimize tuples for runtime indexing without
>> breaking ABI boundaries, but in my case the ABI for my container is fixed
>> per implementation for this one job.
>>
>> >In binary. That means no references, no templates, no special value
>> types, no inheritance, no objects. Just pointers and plain data. The
>> compiler can make it dependent on the list of types, on their properties
>> and common operations.
>>
>> >But apart from that it needs a binary format.
>>
>> ****ANSWER****
>> 1. Again, it can mean all of those if they are efficient for runtime
>> indexing a heterogenous list, like its fixed, but its implementation efined.
>>
>> >Do you want to remove ABI boundaries? That would be a more radical
>> proposal and how should it work at all? Dynamic and to a large degree
>> static libraries, too; operating system calls and callbacks. Compatibility
>> between compilers.
>> >Or your proposal only works, where there is no ABI boundary involved?
>> Just normal functions within a project. Then a lot of library solutions
>> (instead of language change) are perfectly optimizable and will ideally
>> produce the same assembly code.
>> ****ANSWER****
>> NO I DONT. like optimizing a tuple will require that, my proposal is
>> proposing newer expression types and implementation defined containers to
>> not break ABI boundaries. No existing tools are relying on them unlike
>> tuples, so you cant optimize a tuple, but can optimize something new,
>> that's why expanding horizontally always works to be safer than vertically
>> because you don't have the make the base strong or change it.
>>
>>
>>
>>
>> On Wed, Apr 8, 2026 at 1:55 PM Sebastian Wittmeier via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>> At this (early) stage of your proposal it is (in my opinion, others may
>> disagree) not relevant, whether you are talking about std::tuple or
>> std::variant or extreme it or create your own.
>>
>>
>>
>> You have several objects of different types, which are stored inside the
>> object and not on the heap -> that is a tuple
>>
>> You transmit after selection an object with one out of a list of types ->
>> that is a variant
>>
>>
>>
>>
>>
>> ABI boundary means that it cannot be further optimized by the compiler.
>> At the call site, not knowing, what the callee is doing, the compiler has
>> to decide, what to transmit.
>>
>> In binary. That means no references, no templates, no special value
>> types, no inheritance, no objects. Just pointers and plain data. The
>> compiler can make it dependent on the list of types, on their properties
>> and common operations.
>>
>> But apart from that it needs a binary format.
>>
>>
>>
>> Do you want to remove ABI boundaries? That would be a more radical
>> proposal and how should it work at all? Dynamic and to a large degree
>> static libraries, too; operating system calls and callbacks. Compatibility
>> between compilers.
>>
>>
>>
>> Or your proposal only works, where there is no ABI boundary involved?
>> Just normal functions within a project. Then a lot of library solutions
>> (instead of language change) are perfectly optimizable and will ideally
>> produce the same assembly code.
>>
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Mi 08.04.2026 10:36
>> *Betreff:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>> proposed
>> *An:* std-proposals_at_[hidden];
>> *CC:* Muneem <itfllow123_at_[hidden]>;
>> >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
>>
>> -- 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
>>
>> --
>> 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
>>
>