From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-01-08 12:46:59
"Stjepan Rajko" <stipe_at_[hidden]> 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
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
>> 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
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk