From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-08 20:49:07
Steven Watanabe wrote:
> "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
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
> 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 :-).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk