Again, the code is just an example, or the one that is enough to know the
semantics, the container is implementation defined.

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

> 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
>>>
>>