Stjepan Rajko wrote:
* What is your evaluation of the design?
I very much like the simplicity. I'm not sure it really suits the name 'switch_', as I'd expect something syntactically different (something like Joel sketched out in his review, and with some argument forwarding), however, I think it's an important building block that should be kept as simple as possible. I think it should probably be a part of MPL. It would fit perfectly next to 'mpl::for_each' -- 'mpl::for_petrified_constant' or so :). 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. 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). 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?). 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).
* 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).
* What is your evaluation of the potential usefulness of the library?
The implemented functionality is a must-have for metaprogram-driven code generation.
* Did you try to use the library?
Not yet.
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Doc reading & discussion.
* Are you knowledgeable about the problem domain?
Yes.
* Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
Yes, given that handling of the default and the result type is changed as discussed in the design section of this review (or someone makes me change my mind by bringing up even better approaches :) ). Regards, Tobias