Re: [boost] Switch: return type deduction

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-08 20:49:07

Steven Watanabe wrote:
> 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_.  

And because of that, readability, clarity and soundness of the design 
become a minor concern?!

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

Except that the 'result_type' member is in the wrong place (-:

When looking at three headers; one with the 'switch', another one 
defining 'F' and yet another one defining 'Default' it's completely 
unintuitive that valid result types of 'Default' are constrained by 
'F::result_type', for instance.

Another example: Let's say we want to compute a variant type as brought 
up by Joel. Now we'd have to hard-wire knowledge about the cases inside 
the function object. It's pretty obvious that it doesn't belong there.

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

Me not either - the context is gone. I think this one was about the part 
you called "the whole thing" in your first sentence.

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

Maybe I am... Killing time, waiting for your response on the other (more 
interesting?) issues raised in the OP, such as default default behavior.

(-:

Did you miss it, perhaps?

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

That's good. Hopefully I managed to convince you, then :-).

Regards,
Tobias