My latest change to the proposal to make my proposal more complete was in
this email: https://lists.isocpp.org/std-proposals/2026/04/17675.php .

Again, I am sorry for making my proposals incomplete, but I cant complete
the description without knowing what the community wants. I may believe JIT
is the best thing, but someone else might not like it. Plus, I propose
solutions that feel empty, so I can push for radical solutions to show that
small changes often never fix a thing.

On Tue, 7 Apr 2026, 6:07 am Muneem, <itfllow123_at_[hidden]> wrote:

> My response to Mr.Sebistian.
> (Note: I use T^ just as an example of the name, the real name would again
> be up to you guys because I can't make a judgment on syntax with limited
> experience)
> >To keep it simple and stay at the problem once again:
>
>
>
> >From a std::tuple<T, U, V>
>
> >you want to select an element by index (possibly runtime)
>
> >it returns something like std::variant<T, U, V>, but perhaps with
>
> - better support of references
>
> - storing the index used for selection
>
> - custom operation wrappers
>
>
>
> >That std::variant like type allows (common) operations to be called on.
>
>
>
>
>
> >In current C++ I would create a class (UR is a custom class, not inside
> the standard library):
>
>
>
>
>
> class Dispatch
>
> {
>
> public:
>
> Dispatch(tuple<A, B, C> t, int index);
>
>
>
> void op1();
>
> void op2();
>
>
>
> tuple<A, B, C>& _tupleref;
>
> int _index;
>
> }
>
>
>
> >Then the compiler has anything it needs for optimization. What is missing
> compared to your solution?
>
>
>
>
>
> tuple<A, B, C> t = { a, b, c }; // initialize
>
> Dispatch<A, B, C> d(t, i); // select index i
>
> i.op2(); // call operations
>
>
>
>
>
> >No need for new categories or value types or new syntax?
>
> >Full flexibility for customization.
>
> >Full optimization potential.
> ****ANSWER****
> 1. As I said the new T^ would allow for the user to see elements of type T
> in heterogeneous list coming.
> 2. I updated my proposal (in my last email to Mr.thiago) to have a new
> type other T^, that is different (and more type safe) than std::variant.
> ****Limitations in your example****
> 1. I can't pass an element from the tuple in your example to a function,
> and expect an instantion from type_set(selector) to T^(as in my case) which
> can further decay into T or T& or T&&. This is important because without
> this feature your elements in tuple are stuck, and can be passed to a
> function based on runtime indexes without switch statements that I am
> guessing dispatch already has to use.
> 2. Compiler can't use additional book keeping for the switch case
> statements that you are using in dispatch because of the zero overhead
> Principe limiting tuples to be tuples instead of runtime indexed
> heterogeneous lists.
> 3. You cant assign/move to the element that
> d.index is pointing to. While in my case you can (refer to my last
> response to Mr. Thiago:
> https://lists.isocpp.org/std-proposals/2026/04/17675.php), to see the
> additional expression value type that I proposed.
>
>
>
> On Mon, 6 Apr 2026, 4:04 pm Sebastian Wittmeier via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> To keep it simple and stay at the problem once again:
>>
>>
>>
>> From a std::tuple<T, U, V>
>>
>> you want to select an element by index (possibly runtime)
>>
>> it returns something like std::variant<T, U, V>, but perhaps with
>>
>> - better support of references
>>
>> - storing the index used for selection
>>
>> - custom operation wrappers
>>
>>
>>
>> That std::variant like type allows (common) operations to be called on.
>>
>>
>>
>>
>>
>> In current C++ I would create a class (UR is a custom class, not inside
>> the standard library):
>>
>>
>>
>>
>>
>> class Dispatch
>>
>> {
>>
>> public:
>>
>> Dispatch(tuple<A, B, C> t, int index);
>>
>>
>>
>> void op1();
>>
>> void op2();
>>
>>
>>
>> tuple<A, B, C>& _tupleref;
>>
>> int _index;
>>
>> }
>>
>>
>>
>> Then the compiler has anything it needs for optimization. What is missing
>> compared to your solution?
>>
>>
>>
>>
>>
>> tuple<A, B, C> t = { a, b, c }; // initialize
>>
>> Dispatch<A, B, C> d(t, i); // select index i
>>
>> i.op2(); // call operations
>>
>>
>>
>>
>>
>> No need for new categories or value types or new syntax?
>>
>> Full flexibility for customization.
>>
>> Full optimization potential.
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Muneem via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Mo 06.04.2026 03:35
>> *Betreff:* Re: [std-proposals] Fwd: Extension to runtime polymorphism
>> proposed
>> *An:* std-proposals_at_[hidden];
>> *CC:* Muneem <itfllow123_at_[hidden]>;
>> My answer to Mr.Thiago Marciena
>>
>> >So far, all I've understood is that this is a new syntax for simplifying:
>> a) the creation of a std::variant<references, ...>
>> b) visitation
>>
>> That is, if you had:
>> std::vector<Foo>
>> std::map<Foo, Bar>
>>
>> You would implicitly declare a
>> std::variant<std::vector<Foo> &, std::map<Foo, Bar> &>
>>
>> populate it with either a runtime or compile time choice
>>
>> and visit it, calling a function or more in it.
>>
>> It would be up to the compiler to determine that every use of this type
>> compiles for every type in the variant.
>>
>> ****answer****
>> You are mostly right but with some major details left out:
>> 1.the user can overload based of the new expression value type, which
>> allows the user to reason better.
>> 2. This new type can be passed to functions and the compiler will
>> instantiate each function that was found in the overload resolution of each
>> type for this. Which might sound like std::visit but is much more different:
>> 1.for a compile time index, the compiler gurrenties inlining.
>> 2. The compiler gurrenties that returning a heterogeneous set only leads
>> to a pointer move (mechanism is just like exceptions can be captured using
>> references for performance).
>> 3. Unlike std::array or vectors of std::variants, the representation of
>> this list would be completely up to the compiler, hence the code instnatied
>> for each one would be as well.
>> 4. Std::visit can only return a variant, while In my case, for any func()
>> that you pass an element of the heterogeneous list to, the overload of
>> func() chosen for each possible type(of elements in the list) can return:
>> 1.T
>> 2. Or just that type as T^
>> In both cases, unless the user casts the return value of func to specific
>> value T or T^, you can only assign the return value of func tons variable
>> if the variable is variant, unless the index is constexpr, in which case
>> you can assign it to T and the compiler will make sure you get an error
>> unless the type is correct. If any of the functions return T, then the ones
>> returning T^ would be decayed into T or conversely, we could tell the
>> compiler to throw an error (upto comcencess). Std::variants can further
>> enchance this by allowing the usage of variants of type T^, for each
>> std::variant<T^, U^, V^>, this could help function overloads see
>> heterogeneous element accesses coming and handle them. T^ for any T is
>> gurrentied to be the size of a simple pointer.
>>
>>
>> >I don't see how you're solving this problem. There are two issues that
>> cause
>> object slicing: first, it's the calling of a function to implement it.
>> This is
>> easy to do with a virtual function, so a solved problem, but different
>> from
>> copy/move semantics.
>>
>> ***Answer***
>> Problem isn't solved using virtual functions, for example:
>> Base *ptr= new Base{};
>> Dereieved obj;
>> Obj= virtual_clone(ptr);
>> //Slicing so problem is not solved
>>
>>
>> >Second and most importantly: the destination memory area must be of
>> sufficient
>> size to accommodate any of the runtime full objects, which by definition
>> cannot
>> be known at compile time. You are not addressing this problem. And if you
>> come
>> up with a solution for it, then it is also available for the case of
>> calling a
>> virtual function.
>>
>> ***Answer***
>> The destination in this case would either be std::variant or T(if index
>> is constexpr or a explicit cast specifically for this job is created). The
>> specific cast job would also be of a massive help to implement this.
>>
>>
>> >And again: what do virtual functions and object slicing have to do with
>> anything?
>>
>> ***Answer***
>> Because it shows virtual functions are incomplete, say you have want a
>> list of integers, floats, doubles, and you want to do arithmetic, now you
>> have to use either wrap each in variant, in which case you want pass them
>> to overloads expecting this specific case. The compiler isn't given a free
>> hand for the list representation, but rather wrapped in the constraints of
>> a pre existing container that provides gurrenties that pivoted to other
>> motivations. In Mr. Steve's case, it was arrays holding "wrapper clases" to
>> multiple different container type objects. In my case it would be probably
>> very similar to what I talked about in here:
>> https://lists.isocpp.org/std-proposals/2026/04/17641.php.
>>
>>
>> >Same as std::variant then.
>> ***ANSWER***
>> Not the same as variant for the reasons that talked about in the
>> paragraph above. Basically a new heterogeneous list would be pivoted
>> towards representation thats best for itself rather than being in the
>> constraints of the gurrentied behaviours of some other container. Though
>> there would be no dynamic allocating what so ever.
>>
>> >And I don't see how you're solving this problem. This is still the "magic
>> happens" portion of what you've been trying to convey for a week and it
>> seems
>> no one understands.
>>
>> You seem to be saying that one needs to have an overload for each of the
>> possible types, but your solution removes this need. How?
>> ***Answer***
>> The magic portion is that you can provide overloads specifically for
>> these value types T^ that see elements of heterogeneous coming. A even
>> better one would be functions accepting std::variants of these T^ or T
>> types. So the solution to the magic exists, but to take advantage of it, we
>> need that solution to not be constraint by the gurrentied behaviours of
>> current container(in order to make them into lists), and to see the
>> elements of those heterogeneous coming so we can provide overloads for them.
>>
>> >We don't know if it is type-safe, because we can't tell what the type is
>> and
>> how the compiler can reason anything at compile time to prove safety,
>> because
>> we don't understand what you're proposing.
>> ***Answer***
>> 1. It is type safe just like std::visit in that everything is produced at
>> compile time, but also not like solutions based of std::visits:
>> 1. it's not constraint by containers meant used with std::variants.
>> 2. provides more gurrenties like the one I talked about here:
>> https://lists.isocpp.org/std-proposals/2026/04/17641.php.
>> 3.unlike an array of variants, each element has a fixed type, so you
>> can't change it. This makes it more type safe and contained, which also
>> makes it easy to optimize, and provide gurrentied for (constexpr indexes).
>> 4. Because each index has a fixed type, the compiler can further optimize
>> for that aspect.
>>
>>
>> Basically think of it as the better of both variants and tuples.
>>
>>
>>
>>
>>
>> Regards, Muneem
>>
>> On Mon, 6 Apr 2026, 4:51 am Thiago Macieira via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>> On Sunday, 5 April 2026 10:49:34 Pacific Daylight Time Steve Weinrich via
>> Std-
>> Proposals wrote:
>> > He seems to be fixated on a container of some type that returns
>> references
>> > to different type of containers. For the life of me, I can't figure
>> out why
>> > this would be needed or how to make it type-safe!
>>
>> So far, all I've understood is that this is a new syntax for simplifying:
>> a) the creation of a std::variant<references, ...>
>> b) visitation
>>
>> That is, if you had:
>> std::vector<Foo>
>> std::map<Foo, Bar>
>>
>> You would implicitly declare a
>> std::variant<std::vector<Foo> &, std::map<Foo, Bar> &>
>>
>> populate it with either a runtime or compile time choice
>>
>> and visit it, calling a function or more in it.
>>
>> It would be up to the compiler to determine that every use of this type
>> compiles for every type in the variant.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> To keep
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>