Date: Wed, 8 Apr 2026 15:24:45 +0500
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
>
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
>
Received on 2026-04-08 10:25:06