Re: [boost] Switch: return type deduction

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-01-08 12:46:59

AMDG

"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 
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