
Joel de Guzman wrote:
Tobias Schwinger wrote:
FP switch has its place - but it's not what we've got here. This one's about automation.
Huh? The fact that you have a higher order function makes it essentially FP. Even the humblest for_each is FP.
Yes, but that doesn't justify its existence -- the fact that you can easily automate it without using the PP lib does! Both the built-in switch statement and the interfaces you proposed restrict client code to a single number of cases which is known at preprocessing time. Steven's approach OTOH allows the number of cases to vary at compile time. Further, requiring a function object for every case is often not required and just overhead. Picking the simplest interface without these limitations will basically yield what we are currently reviewing.
This utility is about generating the machine code of 'switch'. It does not necessarily have to mimic it's syntax! Why not? Syntax matters! It sure does and elegance is formally defined as the least you can get away with ;-).
And again, it's not just syntax. Why limit yourself to a not-really-a-switch-but-similar library when you can have a real-switch library with all the possibilities that switch can provide -- fallback, individual functions, defaults, etc. Because a not-really-a-switch-but-similar utility suffices in many use cases and provides a more lightweight building block which really-switch can be easily implemented on top of.
That's also a thing a point of disagreement. My solution does not have to be heavyweight. Implementing it on top of the dumb solution, OTOH, will definitely be heavyweight, requiring Fusion.
The fact that we can't do it the other way around (at least not easily -- even given "fused switch") indicates that the current design is the better-suited one for automation purposes!
I don't know what you mean by "other way around".
Implementing Steven's interface in terms of yours is not possible without repeating the PP code.
Why invent another scheme when we can mimic a well-proven, time-tested mechanism, It isn't about inventing -- it's about reducing switch to its essence!
Again, why reduce the essence! To make it lightweight?
Not only. More importantly to make it flexible. Regards, Tobias