Date: Sun, 5 Apr 2026 08:57:02 +0200
> 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).
>
> 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).
Received on 2026-04-05 06:57:17