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.
Granted, both could be combined - exposing some sort of "fused switch" (taking a sequence) and I'd be all for it if compile time was for free.
* I'd be for the "simple" solution if the excess scaffolding you need to add to make it to the truer-switch is compile time free. Transforming the dumb switch_ to a smarter alternative would require Fusion. * The change in interface to what I am suggesting does not have to be heavy in terms of additional code. It's just the syntax, basically. It can be done without Fusion. I know. I did it before. The smarts is almost already in the PP code.
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".
Also also note that the 'switch_' name is obviously confusing :-). Because the API *is* confusing.
I had a look at this utility back when Steven first posted it and had similar doubts. I tried to write Steven about it, but the email never got finished and while trying I realized I got misled by the name.
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? Then, I argue that you are wrong. My proposed interface does not have to be heavyweight. It can be lightweight if done correctly without intervening libraries like Fusion. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net