AMDG
Tobias Schwinger
dan marsden wrote:
Why is the fall through behaviour to throw an exception?
I too tripped over this one, yesterday.
<snip>
The other option is an assertion. Is that any better? Or should a void return type be a special case?
I'm not too clear with the documentation what the parameter 'n' can be?
"MPL sequence of integer constants" and "equal to" are sorta fuzzy in this context, too.
<snip>
OK. I'll tighten this up.
The parameter section does not specify the arities of the 2 function object parameters, I had to deduce them from the example.
I'll be more precise.
Why do these have to be function objects, and not just any callable type, including ordinary functions <snip>
You can use a plain function for default_.
I think "function object" is still the correct term even if you /can/ use a function pointer for the default: A pointer is an object and a function pointer is a function object. A pointer to member function is also Callable -- and we probably wouldn't want to support this case...
Even if it's specified as Callable, it's ok because void int::*() e.g. is illegal anyway.
Of course there are no pointers to templates, so using a function pointer for anything but the default is pretty pointless. So is trying to handle varying result types -- maybe the result type should be passed in with another template parameter?
I'd rather leave it as result_of
Also, why is 'default_' unary, the default in a standard switch statement does not access the switch parameter, and the example does not exploit this feature either. Why not just a nullary function?
I really like this feature a lot:
If you can't react to some case at compile time doesn't mean you can't at runtime...
Exactly.
And finally, as the introduction mentions the efficiency of the standard switch statement, could the docs show some performance stats for the library code for comparison?
Yes, please!
Will do. In Christ, Steven Watanabe