AMDG "Stjepan Rajko" <stipe@asu.edu> wrote:
In case of the former it's a minor concern to just pass in that type. I'm pretty sure the resulting client code will read clearer (that is without having to dig up the docs).
IMO, the whole thing is a minor concern. I don't expect people to use general purpose function objects with switch_. (It has to take MPL integral constant wrappers and sort out what to do using some kind of metaprogramming). Thus, it's just a matter of specifying the return type inside the function object or specifying it at the call site. The use of result_type is not exactly unprecedented... The name result_type seems more self explanatory to me than a bare template parameter.
The latter seems to me as a misguided approach that encourages users to mess up the result type computation of their function objects.
I beg your pardon? I don't understand.
I disagree. Good code is self-explanatory. Good libraries encourage good style. Weird stuff stays weird and documenting it doesn't change it ;-).
Maybe I'm just blind - but I see absolutely no benefit from attempting to deduce the result type over having the result type specified by the user.
I think you're overstating your case. Requiring a function object to have a unique return type specified by the nested typedef result_type is hardly weird.
I don't think you're blind - for the most part, I'm just throwing out possible viewpoints to see if anyone else sees any validity behind them, and to know what to recommend at the end of the review. Thank you for providing great arguments for your view - unless the author or other reviewers feel strongly otherwise it seems like the most reasonable way to go (and thanks to Joel for joining the discussion!).
Agreed. I don't have a strong opinion on this point. In Christ, Steven Watanabe