Thank you for your feedback ❤️ ❤️
****Short answer****: the semantics and implementation would look something
like this:
Func(selecter(index)): (if func was a member function then every type must
have func but the possible implementations will remain the same, selectors
can also be further constraints by concepts, just like templates can be)
***Semantics***
Overload resolution is done to find the N number of func() functions, where
N is the amount of types. In both cases,(for every x func() found) Func can
be either of two:
1. It's a normal function taking T, in which case "selecter(index)"
expression decays to T. The semantics (for the programmer) of usage of that
object of type T remains the same.
the implementation in this case would look like:
***Implementation***(up to the compiler but can be either of these or many
more than thede):
(Note: you don't have to use a particular representation of the objects
with a particular instation form of the code)
***Code instantion for each type***
Where instating a particular function or a block can lead to more overhead
(instruction cache trashing) than vtables or similiar techniques, then
vtables would be used, else branches or jump tables, code of the functions
for multiple types can be shared and jumped to by multiple types. Here it
is more flexible because the compiler can decide on a per type basis in the
function body. This all happens at the point instantion which is the first
time when func() is called. Once the body is expanded for each type.
***Storage of objects***
each group of objects of the same type have their own array, and each of
that array(right before the arrays of the rest of objects) is stored in
another array (say as void* conceptually). Then the compiler takes your
subscript and figures the best calculations that it can do to find the best
way to subscript these two arrays, so say the selecter is: {1,2, 2.2, 'a'}
selecter(int) now the compiler can be:
( (index xnor 3) Shift right 1)
as the index for the array containing arrays of the same object. Then the
index inside of each array could be:
Index % 3
Modern compilers already use complex techniques to find the best floating
point representations for floats, so this possible implementation should
not be hard. This possible implementation can be one of many the compilers
pull up its sleeve. In fact, I was using pmr::monolithic resource with
pmr::allcoator in my code but If I had to, I would use this techniques for
subscripting in it. This would probably require somes math formulas(gonna
work on it).
***Storage of objects***
**Technique number two is from my virtual machine.**
Memory for all objects is allocated first (using pmr:: monolithic memory
resource, then a vector<void*> was constructed containing pointers to
objects. In this case would be array of void* (in concept ofcource). The
goal would be to not store or check for type information at runtime, but
instead using some formula to derive what I derived below:
say the selecter is: {1,2, 2.2, 'a'}
User wants 'a', instead of storing or checking the type of a at runtime, we
compute the index(in the jump table) to the code for the type "char" by
((index xnor 3) shift right 1), then we jump into the jump table. The code
representation of each branch of the jump table can be as I described
before.
***Second case:***
2. If func() is special because it doesn't take a normal argument, but
rather an argument T of the new expression type, then the user can be
provided with additions constructs that help him manually inspect The obj.
I would say it can look like this
For {1, 1.1, obj}selector(index)
Selector{1}
Int func(const/volatile/or-non int^ obj)
{
//Custom code
}
//float isn't here because the func() for float was a normal func() that
takes float
Template<typename T>
T func(const/volatile/or-non T^ obj){
//Could be used for constructors as well
Return std::move(obj);
//Virtual clone functions are buggy because what if you are assigning to a
dereieved class from a *base_obj!? That's why I say that virtual functions
are an incomplete solution to everything!
//Type T^ can be the return type as well
}




Individual answers to your questions:

A prototype implementation would help a lot. 1) It might help us understand
what you really want (because we all understand at most 70%). 2) We suspect
that it is just syntactic sugar and under the hood it is the same as what
we can do right now which would mean that the optimizations are the same.
Your prototype would show that we are wrong. 3) It would force you to think
through all the problems and provide solutions to them. Without a proof
that what you propose is possible it is too high risk to consider for
standardization. We standardize things we know are possible (or have
reasonable belief that they are possible).
***Answers***
1.i am sorry that I underestimated the importance of possible
implementation, but it's just that I am trying to play all sides of the
discussion, and some people won't like to discuss low level details (cuz
they see it as implementation details).
2. Are rvalues syntactical sugars? Why no?
Because they provide move semantics, guaranteed optimizations, and allows
the compiler to optimize every move object away because accessing move is
undefined anyway, and moved object can be get ridden of unless the
destructor contributes to the observable behaviour.
3. You are completely right and I am sorry for underestimating it.



> 1.I showed my own code to show the issue with verbosity of switch case
statements
Yes, you showed us a single example out of the millions of code bases that
exist around the world. That alone does not make it worth standardizing.
Nobody has checked if there are better design choices for your code.
***Answer***
Ouch, but you are right. I know my example isn't important sorry for
bringing it up too much, I showed it because some asked for a real example,
and my example was one that I could relate the most to.





>And verbosity alone is also not a reason for standardization. We have
explained before that template for and reflection (if used correctly) can
reduce the verbosity of the code (but still compile to the same thing).
***Answer***
What I meant, wasent a fancy syntax for switch case statements to reduce
verbosity, but rather to provide new semantics that decrease the verbosity
of optimizations that one has to do. For example:
1.to std::move from a variant, you have change your entire design pattern
to revolve around that issue.
2. You can't help the user provide overloads that target unions.


> 2. Then, I went ahead and tried to debunk why virtual functions don't
allow templates to be used, can't be moved, and are too rigid and
incomplete for this task.

>I see several proposals here: 1) A proposal to allow templates for virtual
functions. 2) Allowing move semantics for polymorphic types (maybe by
allowing the move constructor to be virtual?). However, I only have a
polymorphic type with a pointer or reference which means that this is not a
question about constructors. I don’t think there is a restriction on move
assignment that it couldn’t be virtual. It is always better to push for
small changes in existing features (especially if they don’t only help you
in your problem, but also help others) instead of introducing new features.
***Answer***
1. Virtual functions cant be templates because that would lead to confusion
on which function overrdies which.
2.move assignment can be virtual but thats worse because again weak
foundations lead to this:
Dereieved a = std::move( *base_ptr );
Which means that the base class version of operator=() would be called for
dereieved A. Which is a massive issue. This is a difficiency for all
operators or virtual functions that make you think twice before using one.
This is unlike mine, where the function chosen for "T^ obj" is known at
compile time.


>Concerning moving polymorphic objects: Right in the beginning of object
oriented programming people also thought about a clone() member function to
do polymorphic copies. Move semantics didn’t exist back then. There is
nothing holding you back to write a move() member function that does a
polymorphic move in the same way. Just saying that there is an easy
solution.
***Answer***
Again, imagine this:
Dereieved B;
B.clone(*base_obj)
This suffers from the same issue that I discussed that virtual operator
functions suffer from in the previous answer.

> 3. People do care about move semantics because they are what makes RAII
so efficient and fun to use.
RAII was invented long before move semantics existed. And people wrote
efficient code in C++ for over 2 decades before move semantics were
available. Things were just a little harder before.
***Answer***
Things were a little harder, but not everything was scalable. In that move
semantics didn't just change std::move, it allows the compiler to built
objects in place and even gurrenties it sometimes. Before, you had to do
book keeping in your mind ( I remember using C and C++ (without using move
semantics) when I was 13 to 16). Infact book keeping burden is why I moved
to c++ because it just leaves it all to the compiler. Rvalues are great
example, it's all upto the compiler and I don't have to deal with unless I
provide rvalue function overloads.


> 4. Relying on gurrentied semantics isn't compiler magic, it's the
fundamental building blocks of any language.
Currently, your “guaranteed semantics” are magic to us. We are unsure what
you want to guarantee by your semantics (maybe you want to guarantee that
indexes are used; but I don’t think it is smart to put that into the
standard because depending on the architecture other solutions might be
faster -> lookup tables used to be faster than switches but nowadays memory
is so much slower and branch prediction is so much better that the opposite
is true now in certain cases => this means: let the compiler decide on the
most efficient implementation).
***Answer***
By gurrentied semantics, I mean, that for any object of type T of this new
expression value type:
For now potential ones might be:
1.The code branch is to be gurrentied to be found at compile time if the
index is constexpr. (Avoid repeating code for runtime indexing and compile
time indexing, by one using this and the other tuple).
2. Returning T^ should be cheap *move*(incur just a pointer copy cost) all
the list of items and any book keeping information into the parent function
stack at runtime.
3. If the subscript is used once in a loop, then it should be gurrentied
that branching based on the correct code for the type won't happen again,
though the indexing among objects of the same type can happen.
4. Even though T^ can be returned, it must be casted (using a new cast
operator) to T to be assigned to a object of type other than T^
I certainly fail to see the parallels between your proposal and rvalues. I
would rather claim that rvalues was a bottom up design: we first knew how
to do it and then thought about the syntax. Also copy elision and return
value optimization was introduced into the standard because some compilers
did it. Named return value optimization was introduced into the standard
even later. The chicken and egg situation is certainly reversed compared to
your proposal. Also, rvalues (if I’m not mistaken) go down to the IR and
don’t optimize on the level of the AST. If your optimizations can only be
done on the AST, this is certainly a totally different thing.

***Answer***
1. Our compilers are already smart, but the issue is that we don't have a
construct that provides semantics. So we have a lot to do it:
Vtables for every line code or every few lines in the function body,
branches if you want, or anything the compiler sees fit. We have the
infrastructure but not the semantics.

2.Certain rvalue optimizations don't happen at the AST levels, for example:
1. the move semantics in which the compiler chooses which function to call.
2. Copy elision.
Yes there are other optimizations that take advantage of the fact that
accessing rvalue after move is undefined but those are not language
optimizations and for those rvalues can be seen as syntaxtical sugar, and
so can my one be.


Don’t just use “guaranteed semantics” as a buzz word, but actually describe
what you want to guarantee. And as I said before: you need to provide more
than just a single example (your Turing virtual machine) why compile time
known heterogeneous lists are useful to others. The only thing that I found
on the internet is for runtime generated heterogeneous lists.

***Answer***
1. I provided the gurrentied in th answer to your paragraph numbered as
">4".
2. The reason compile time known heterogeneous lists are good is because it
expands the notion of metaprogramming to arrays.
3. The facilities provided by the solution to heterogeneous lists would end
up providing a new expression value type that as I said would provide safer
move semantics (no clone functions), the user a chance to handle them (by
specific overloads), and the gurreenties that I specified.


> 5. Then, I argued that std::visit is a fancy construct for switch that
fails at removing code that in your words " does nothing ", which is
failure that matters because we do right code that does nothing, in fact in
my virtual machine, instead two switch cases, one for runtime switching and
the other for compile time, I wrote one, and to implement the compile time
one, I simply made it a template that took a integer index and gives it to
the other function. This technique worked and assembly was shortened by a
lot.


Typically you would not write switch statements for templates, but use a
non-type template argument and specialize templates on that. This is
actually how template metaprogramming was started by Erwin Unruh. And if
the optimizations for std::visit are insufficient (on one compiler) we
should work on better optimizations on that because std::visit is already
in the standard and people are already using it. It is always a good idea
to make existing code faster if possible by just changing the compiler. I
already mentioned before that in theory std::visit could also be
implemented by indexing (automatically, as an optimization).

***Answer***
1.I did the same, it was a int template argument, I may be 17, but still
not that bad at code.
2. Std::visit doesn't can't architecturally:
1. Fix the virtual clone() function problem.
2. Can only return a variant object, and can't return I objects of
different types.



On Sun, 5 Apr 2026, 11:57 am Simon Schröder via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

>
>
> > On Apr 5, 2026, at 5:42 AM, Muneem via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > Answer on why I didn't provide a implementation prototype yet:
> > 1. I can't prototype my implementation since the resulting code would be
> implementation defined, the only thing that isn't is the expression value
> type gurrentied semantics and how it would help people by writing overloads
> for that new expression value type.
> > Semantics is always the first step to a prototyped implementation. A
> predator can't catch its prey if it hasent even seen one. Seeing one is the
> core semantics, while catching it is the possible implementations.its like
> if rvalues were to be implemented, what would come first? Semantics of
> course.
>
> A prototype implementation would help a lot. 1) It might help us
> understand what you really want (because we all understand at most 70%). 2)
> We suspect that it is just syntactic sugar and under the hood it is the
> same as what we can do right now which would mean that the optimizations
> are the same. Your prototype would show that we are wrong. 3) It would
> force you to think through all the problems and provide solutions to them.
> Without a proof that what you propose is possible it is too high risk to
> consider for standardization. We standardize things we know are possible
> (or have reasonable belief that they are possible).
> >
> > Rest of the answers:
> > 1.I showed my own code to show the issue with verbosity of switch case
> statements
> Yes, you showed us a single example out of the millions of code bases that
> exist around the world. That alone does not make it worth standardizing.
> Nobody has checked if there are better design choices for your code.
>
> And verbosity alone is also not a reason for standardization. We have
> explained before that template for and reflection (if used correctly) can
> reduce the verbosity of the code (but still compile to the same thing).
>
> > 2. Then, I went ahead and tried to debunk why virtual functions don't
> allow templates to be used, can't be moved, and are too rigid and
> incomplete for this task.
>
> I see several proposals here: 1) A proposal to allow templates for virtual
> functions. 2) Allowing move semantics for polymorphic types (maybe by
> allowing the move constructor to be virtual?). However, I only have a
> polymorphic type with a pointer or reference which means that this is not a
> question about constructors. I don’t think there is a restriction on move
> assignment that it couldn’t be virtual. It is always better to push for
> small changes in existing features (especially if they don’t only help you
> in your problem, but also help others) instead of introducing new features.
>
> Concerning moving polymorphic objects: Right in the beginning of object
> oriented programming people also thought about a clone() member function to
> do polymorphic copies. Move semantics didn’t exist back then. There is
> nothing holding you back to write a move() member function that does a
> polymorphic move in the same way. Just saying that there is an easy
> solution.
>
> > 3. People do care about move semantics because they are what makes RAII
> so efficient and fun to use.
> RAII was invented long before move semantics existed. And people wrote
> efficient code in C++ for over 2 decades before move semantics were
> available. Things were just a little harder before.
>
> > 4. Relying on gurrentied semantics isn't compiler magic, it's the
> fundamental building blocks of any language.
> Currently, your “guaranteed semantics” are magic to us. We are unsure what
> you want to guarantee by your semantics (maybe you want to guarantee that
> indexes are used; but I don’t think it is smart to put that into the
> standard because depending on the architecture other solutions might be
> faster -> lookup tables used to be faster than switches but nowadays memory
> is so much slower and branch prediction is so much better that the opposite
> is true now in certain cases => this means: let the compiler decide on the
> most efficient implementation).
>
> I certainly fail to see the parallels between your proposal and rvalues. I
> would rather claim that rvalues was a bottom up design: we first knew how
> to do it and then thought about the syntax. Also copy elision and return
> value optimization was introduced into the standard because some compilers
> did it. Named return value optimization was introduced into the standard
> even later. The chicken and egg situation is certainly reversed compared to
> your proposal. Also, rvalues (if I’m not mistaken) go down to the IR and
> don’t optimize on the level of the AST. If your optimizations can only be
> done on the AST, this is certainly a totally different thing.
>
> Don’t just use “guaranteed semantics” as a buzz word, but actually
> describe what you want to guarantee. And as I said before: you need to
> provide more than just a single example (your Turing virtual machine) why
> compile time known heterogeneous lists are useful to others. The only thing
> that I found on the internet is for runtime generated heterogeneous lists.
>
> > 5. Then, I argued that std::visit is a fancy construct for switch that
> fails at removing code that in your words " does nothing ", which is
> failure that matters because we do right code that does nothing, in fact in
> my virtual machine, instead two switch cases, one for runtime switching and
> the other for compile time, I wrote one, and to implement the compile time
> one, I simply made it a template that took a integer index and gives it to
> the other function. This technique worked and assembly was shortened by a
> lot.
>
> Typically you would not write switch statements for templates, but use a
> non-type template argument and specialize templates on that. This is
> actually how template metaprogramming was started by Erwin Unruh. And if
> the optimizations for std::visit are insufficient (on one compiler) we
> should work on better optimizations on that because std::visit is already
> in the standard and people are already using it. It is always a good idea
> to make existing code faster if possible by just changing the compiler. I
> already mentioned before that in theory std::visit could also be
> implemented by indexing (automatically, as an optimization).
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>