Add on top of it, C++ UB superpowers, and it becomes lethal.
Second of all,
I'm still stuck in C++17, by choice.
So if this proposal or a similar is already implemented somehow, then I'm sorry, because i didn't know.
Again, my motivation was simple, just keep every peace of information available.
But when i started developing the idea, it was a lightning strike.
Making the compiler create variants and code using it, ad hoc, was amazing. Because the compiler has information about all the types available in the program, yet we cannot query them.
Honestly, i don't know the extent of the benefits of this proposal, I'm still discovering it with you all.
But one use case that comes to my mind right now, is signal and slots.
Usually we implement slots as function returning void, but in real life, slots can return anything.
So what if i need to use the return values of a series of slots connected to a signal?
Don't tell me use std::any...
Because if you want to read data from that std::any you need to know what type you should cast it to, because slots are of arbitrary return type.
For example:
Signal. Slots
int(*)(int, double)
void(*)(int,double) char(*)(int,double)
struct S (*)(int, double)
If you collect arbitrary slots in a container, they have to get the same type
vector<??(*)(int, double)>
If you replace ??<-> std::any, so in a loop how will you process that data?
How will switch based on the return type of the slot?
To what are you going to cast that std::any?
Because of this, most implementation of signal and slots throw away the slots return value.
That's one example on top of my head.
The fun about this proposal, is the idea of inventing a compiler planner, that can prove at compile time what to generate.
When to unroll a loop?
When to stamp a switch function?
How to consolidate different generated functions?
...and so on.