Re: [boost] Switch: return type deduction
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
Steven Watanabe wrote:
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_.
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
AMDG Tobias Schwinger <tschwinger <at> isonews2.com> writes:
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?!
I didn't say that. I could read either one without any difficulty. Thus, it's a minor concern because the impact on the above is small.
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.
OK. Now I'm convinced.
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.
Yep. In Christ, Steven Watanabe
participants (3)
-
Steven Watanabe -
Steven Watanabe -
Tobias Schwinger