AMDG
Tobias Schwinger
As pointed out in other posts I think the default default case behavior should be changed not to throw but to use the default constructor if no default case function object is specified.
Will do.
A default case function object returning 'void' should be assumed (and 'assert'ed) not to return in a context where a (non-void) result is expected (implementation hint: the built-in comma operator allows void arguments and an overloaded comma operator doesn't).
Personally, I'd rather just forbid a default that returns void when the return type is non-void. I don't think the comma operator is a completely fool-proof way to detect void. It could cause an ambiguity if the other type also defines an overloaded comma operator.
As also pointed out and discussed in other posts I'm very much for having the result type specified explicitly (as opposed to deducing it from the function object).
* What is your evaluation of the implementation?
Again, I like the simplicity. Keep it this way:
If "fallthrough cases" are going to be implemented it should be done in another template (or should it even be a full-blown Duff loop?).
Fallthrough cases make a lot more sense with a fusion sequence based interface.
Another variant of the template taking min/max instead of a sequence might be a good idea, as it can make things compile faster in many typical use cases (well, that would be half-way a design thing).
I'll consider it. Provided I can measure a speedup, of course.
* What is your evaluation of the documentation?
Works for me.
As mentioned before, the reference could be more detailed at places, regarding the equality with MPL constants and the exact types passed to the function objects (even if overloading operator() is uncommon - it might be occasionally useful to deduce a non-type constant from it).
As Dan Marsden mentioned, I can easily imagine dealing with special cases such as zero by overloading. Thanks! In Christ, Steven Watanabe