Hi!

I couldnt sleep because when I close my eyes, tears come which makes pain just heat up, so I spent a few hours thinking and combining an answer to all your welcomed questions and feedback in one email:

(The answer to Sebastian and Thiago is in the end)

I will try to first summarize my construct in it's latest form and the issue it solves before giving answers to individual emails and naming everyone who was kind enough to send them:

****Short form****

What is the problem:

The probably with classic polymorphism used as the implementation, ie:

Std::vector<base*> 

Is that it:

1.Does not provide a new expression value type that can have its own unique semantics on a language level.

2. Does not let the user move the polymorphic objects (constructors cant be virtual).

3. Too verbose

4. You can't use expression templates (literally a feature considered normal at even books written in 2013).

5. Does not give a free hand to the compiler by providing the intent that I am trying to index, which might make the abstract tree look too abstract(hiding intent) to be optimized.

Many more points but I don't want to make long (plus my left eye hurts so I want to write this fast).

Philosophically: the problem is that the solution is too incomplete, and tries to be too general.

Solution:

My construct that provides:

1.A new expression value type of the set

2. A new expression value type of each element in the set:

*The second one would introduce the special features*:

1.Just like rvalues introducing move semantics, this new value type can introduce user defined optimizations, and it would introduce itself into the abstract tree making it easy to optimize the abstract tree. 

2.the compiler has to produce the code it thinks is the best based on the usage of the expression of this value type. Variables can be of this type, infact we can have a whole class of optimization just like move semantics that revolve around this new expression type.

My full detailed answers to Simon and Mr Marcin:

Thank very very much for your feedback!!!!

(All answers are ordered by number, so number if you numbered your point "1)" or "1", I would number it "1"), and If there is no numbering then I don't number myself.

> I believe the picture is now getting clearer (Muneem, please correct me if I am misrepresenting your ideas). At compile time the type of x is not known. This is one of the reasons why Muneem suggested to use a JIT: just include the source code/AST/intermediate representation in the executable and finish compilation (using the JIT) when running the program. I see several problems with this: 1) C++ programmers love their performance. Waiting for JIT compilation is going to be slow. And every time we hit this place we might have to look up if the function has already been compiled for this type (which is a branch, of course, that we wanted to avoid). 2) If I want to call x.capacity() the member function needs to be linked in the executable. Linkers currently will only link the functions that are used by the program and eliminate all other functions. The reason is that we want to reduce the size of executables. 3) This is even exacerbated if we are using template types like std::vector: Its member functions are not available in any library that could be linked, but templates are instantiated when used. This means that we can’t even pre-generate all possible instantiations of std::vector::capacity (which through recursive use of std::vector are infinite) to be linked into the executable. At least with this approach it is highly questionable if the advantages of the proposal weigh heavier than the disadvantages I have mentioned. Most people most likely prefer smaller binaries and shorter compile time (less unnecessary template instantiations). It also is in contrast to the zero overhead principle: in order for this to work we would have to link everything every time even if we are not using this feature.

> Now, I’m taking a turn to heterogenous lists: I didn’t know what these were and I’m not sure I understand them well enough to make a fully qualified judgement.

***********Answer***********

1. My original proposal (the one with JIT) was very general, and meant to be narrowed down through feedback and criticisms.

2. The same can be said about std::variant:

The compiler would instantiate capacity for all containers, but the ****difference in my case****:

3.I am introducing two new expression types to optimize this, one is obviously for the set and the other is the element type of the set. 

****Why is this important****:

For every indexing point, the compiler can make decisions on whether to use vtables, whether to instantiate, which might sound the same as std::visit but for this case:

As described before in the short answer that the expression value type will help allow users to provide optimizations, like rvalues do using move semantics.

It will also decide whether it can do extra optimizations (it has in the abstract tree due to the new expression value types) without impractical compile time overhead at an intermediate representation, which isn't the case with std::visit which either can be traced impractically or just left out.

***********Answer***********

>

> First, for the problems they are trying to solve: From what I can find they could be helpful when parsing JSON or XML or when returning results from SQL queries. However, if I’m not mistaken, all these formats have a known number of possible types. In general, in C++ we could use either std::variant or subtyping polymorphism to restrict the number of possible types in the heterogeneous list.

***********Answer***********

 Let me try to clarify: 

Std::visit is proven to be slow in my discussion with mr.thiago, who said that we should wait for compiler backends to become faster, which is irrelevant because c++ is supposed to have constructs that make it fast on an intermediate representation level. It can't even be optimized on an abstract tree level and/or dosent provide std::move(variant_obj)

***********Answer***********

>

> Muneem mentioned the programming language Go as an example. Go does not have subtyping. Instead, you can define interfaces. Traditionally, heterogeneous arrays have been defined as type []interface{} which is an array of an empty interface (disclaimer: I have never written a single line of Go). The empty interface somehow allows to store any type. The modern version of this seems to be to use an array of the ‘any’ type. This would perfectly map to std::vector<std::any> in C++. The example that I have seen is that it is still possible to at least println() every single entry inside an []interface{}. So, there needs to be some sort of runtime polymorphism. This again has the aforementioned problem of instantiating all templates and linking all functions.

***********Answer***********

Yes, std::visit has the problem(described the last sentence of your paragraph) of instigating all templates, as shown in answer to your paragraph 2. GO was honestly a very bad example, but I used it because I learned GO a few years ago(when I was 14) and the experience I had was good(easy to learn), so I didn't think twice before using it, but I stopped using it because it isn't enough to get things done (only c++ is).

***********Answer***********

> Let’s think about how we could achieve runtime polymorphism for std::any (I don’t know how Go is actually doing it): First version that comes to mind would be to use runtime reflection and reflect on the string of the function name (e.g. “capacity”). This gets more complicated if function overloading is involved. (BTW, from what I have read about heterogeneous lists in C# it is convenient to use them, but slow!) Still, this does not achieve the goal of Muneem for this solution to be fast. We would need string comparisons and branching. I do believe that a decently fast solution would be possible as the Objective C runtime from Apple has shown (they use some clever tricks with caching, etc.). Still, it would add a performance overhead.

***********Answer**********

C# is a bad example because c# doesn't support move semantics (among other things) and instead relies on garbage collection. The problem isn't there in c# because it is inherintly slower due to the lack of these features (rvalues, copy elision, and probably countless many more).

***********Answer***********

>

> Muneem also mentioned something about indexing. What I could imagine is a function pointer for each entry in the heterogenous list. We could easily achieve something like this with std::vector<std::pair<std::any,std::function>> (or directly a function pointer instead of std::function). Then we could use the function pointer through the same index as the object. This gets more complicated if we want to have more than just a single function pointer. And we would need make it easier to create these kind of heterogeneous lists without explicitly mentioning which functions we want to have function pointers to. Also, if you have objects of the same type inside the heterogeneous list we might be able to reuse a set of function pointers and thus optimize storage. This sounds a lot like vtables. So, with this approach we have reinvented regular C++ runtime polymorphism.

***********Answer***********

But this technique also has fixed the problem of providing the optimizations that c++ already has (move semantics, copy elision) to "regular polymorphism".

***********Answer***********

> As I have demonstrated before, std::any has problems with template instantiations and linking. An efficient solution (both in space and time) would need to know the exact types possible in the heterogeneous list. This kind of brings us back to std::variant. I would say that the current solution of std::visit over Muneem’s proposal is that I don’t have to figure out/know the index of the function I want to call on an object. std::visit is doing the job for me depending on the type. We could add some syntactic sugar and allow operator-> on std::variant to basically do the same job as std::visit with an automatically templated lambda (or even better with operator. if we get that one into the standard). The compiler might actually create a list of function pointers (even now with std::visit) that can be indexed based on the type. I don’t know if function pointers are better in any way for std::visit than the solution we have right now.

***********Answer***********

The compilers can do optimizations on abstract tree level, but without significant overhead, it can't do those on std::visit. At least not to counter the fact that move semantics are missing(constructs can't be virtual).

***********Answer***********

>

> One thing I observe in Muneem’s examples is that the heterogeneous list is known at compile time. And the difference is that std::visit does polymorphism on function calls and what Muneem seems to envision is polymorphism on the object (type), i.e. when accessing an object from a heterogeneous list I don’t get a polymorphic object, but the object of its exact type. The biggest hurdle in this is how to get a runtime index into a compile time template parameter (preferably automatically): std::get<i>() on a std::tuple only works for compile time known values of i (some examples might work with the new ‘template for’ from C++26 reflection when iterating over all entries of the heterogeneous list if using a std::tuple). I’m currently stuck at this point (especially with Muneem’s actual problem with his Turing virtual machine).

> Muneem, one last thing: I’m not sure if heterogenous lists are currently fast in any language. If you know of a truly efficient implementation worthy of C++ in any language, let us know. And with the way you are currently describing it I’m not sure if it works with a static type system. We would need to map runtime known indexes to compile time known types. This is practically impossible.

***********Answer***********

I don't think any language relies on expression types for 90% of their optimizations, like we guys relies on rvalue references so much that I can't believe a life without it, yet we are hesitinant to add a new expression value type.

***********Answer***********

> --

But isn't this classic XY problem?

If `std::variant` vs `switch` matter, why do any check in this place of code?

Move the check a couple of layers higher to avoid polluting tight loops with it.

Like:

```

void foo(int i)

{

    switch(i) { ... }

}

void bar(int i)

{

    for (auto& x: data) for(i);

}

```

change into:

```

template<int i>

void foo()

{

    //code based on i, like `std::get<i>`

}

void bar(int i)

{

     switch (i){

          case 0:

               for (auto& x: data)

               {

                    foo<0>();

               }

               break;

          case 1:

               for (auto& x: data)

               {

                    foo<1>();

               }

               break;

          //etc.

    }

}

```

Now the compiler has MORE info and an easier time to optimize each loop.

Only only problem I have is `switch (i){` is tidus to write, but it

could be easy fixed if `case:` can be expanded in `template for`:

```

template<auto Indexes>

void bar(int i)

{

     switch (i){

          template for (constexpr int Index : Indexes)

          {

               case Index: for (auto& x: data) foo<Index>();

               break;

          }

    }

}

```

This will allow easy transition from runtime value `i` into template

value `Index`.

It happens often like "how to deserialize `std::variant`?"

***********Answer***********

The technique you showed would almost always backfire without context that only abstract tree can provide. To give that abstract tree context, the compiler needs to see the whole abstract tree to make the best possible decision, and for that, it need a value type representing this index.

***********Answer***********

>Please learn how to properly reply to emails instead of duplicating it

two times as it is impossible to properly answer them on a mailing

list.

***********Answer***********

I am really really sorry

Why I do it by mistake:

I am just a 17 year old guy who is trying to make his code shorter and make fun of his brother who uses AI to write code by saying:

I use metaprogramming instead (proceeds to say "code that writes" code to his brother).

When I get bombarded with fun questions, I get too excited, so I try to respond fast.

***********Answer***********

>I did not use std::variant or std::visit in my “standard approach”. Please look again and identify your issue(s).

***********Answer***********

I am really really sorry, I updated my email to clearly explain the problems

***********Answer***********

>It is a heterogeneous collection, so it is more like std::tuple.

***********Answer***********

Yes and no. It's a no because it introduces new value types on a abstract tree level

***********Answer***********

>I think others on this list have understood your idea faster than me, and already gave feedback, when I still tried (am trying) to understand, what is was about.

 

 

After the problem statement, to understand your idea for speedup. You talked about cashlines and less indirect accesses and therefore rejected a vtable based approach.

 

Now I am trying to understand your low-level solution:

 

 

If in your vector (of containers or other types) we store the following

 

[1]

pointer to Type1.op1()

pointer to Type1.op2()

instance of Type1 (directly stored in full length, not as pointer)

[2]

pointer to Type2.op1()

pointer to Type2.op2()

instance of Type2 (directly stored in full length, not as pointer)

[3]

pointer to Type3.op1()

pointer to Type3.op2()

instance of Type3 (directly stored in full length, not as pointer)

 

 

So instead of the indirection over a vtable, you directly get the function pointers, but with the cost of the entries being longer, as with each entry all the used operations have to be stored for that type?

Type1.op1()

Type2.op1()

Type3.op1()

 

all would have the same call signature. So no switch or branch is needed.

 

 

Is that what you want under the hood?

***********Answer***********

Hi, Mr.Sebastian

Was hoping for you to join this wonderful discussion. What's under the hood would be determined by the semantics of this new value type that I am willing to discuss and debate.

***********Answer***********

void foo(int i)

> {

> switch(i) { ... }

> }

> void bar(int i)

> {

> for (auto& x: data) for(i);

> }

> ```

>

> change into:

>

> ```

> template<int i>

> void foo()

> {

> //code based on i, like `std::get<i>`

> }

> void bar(int i)

> {

> switch (i){

> case 0:

> for (auto& x: data)

> {

> foo<0>();

> }

> break;

> case 1:

> for (auto& x: data)

> {

> foo<1>();

> }

> break;

> //etc.

> }

> }

> ```

Compilers already do that on their own.

They may not be doing that all the time, though. So if you do need to enforce

this, implementing manually may be necessary.

Do we need a new language construct for this? Especially in the presence of

template for?

Please provide the proof that you've used to make the assertion that it is

hard to optimise at the intermediate representation level.

In addition, you've said this problem is widespread. I've asked before and

will ask again: please provide links to 10 different cases where it is visible

or was fixed/worked around in existing, open source codebases. You should have

no problem finding at least 3.

I'm asking this so you realise that you may be making unfounded claims. If you

want to argue that it must be so, prove it. Otherwise, please rephrase your

statements to indicate that the problem may not exist at all, except in your

one case.

***********Answer***********

Your example shows that I mean, compilers convert them into switch case statements on a assembly level, not on a abstract tree level. We need a new value type to change the value abstract trees work.

Try moving a polymorphic object using std::move, and you will see how widespread the problem is.

***********Answer***********

On Sat, 4 Apr 2026, 8:41 pm Thiago Macieira via Std-Proposals, <std-proposals_at_[hidden]> wrote:

On Friday, 3 April 2026 21:39:04 Pacific Daylight Time Muneem via Std-Proposals
wrote:
> The current techniques/(std::variant) is to verbose and too hard to
> optimize at a intermediate representation level.

Please provide the proof that you've used to make the assertion that it is
hard to optimise at the intermediate representation level.

In addition, you've said this problem is widespread. I've asked before and
will ask again: please provide links to 10 different cases where it is visible
or was fixed/worked around in existing, open source codebases. You should have
no problem finding at least 3.

I'm asking this so you realise that you may be making unfounded claims. If you
want to argue that it must be so, prove it. Otherwise, please rephrase your
statements to indicate that the problem may not exist at all, except in your
one case.

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