Re: [boost] [Boost-users] upcoming Switch library review Jan 5th - Jan 9th
On Jan 6, 2008 12:20 PM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
Stjepan Rajko wrote:
Would using result_of<F(boost::mpl::front<Cases>::type)> be an option for a non-empty case sequence?
I think it's too complicated: We can't use 'result_of' to determine the result of 'switch_', so it should be as simple to determine as possible (ideally without deduction at all).
Sure - although the library could offer something along the lines of result_of::switch.
As long as the order of the cases doesn't matter (btw, does it?), the user could put the desired type in the front of the Cases sequence if the return type differs for different MPLConstant types.
Further, we still need a special-engineered function object; one of the cases will have a special role. It might work, but it feels inelegant to me: The function object's result type should be convertible to whatever 'switch_' wants to return.
I agree that being able to specify the return type explicitly would be very useful, precisely because you could use function objects that are not result_of/result_type compatible, or override the return type even if one is specified by the function object. I can see overriding it to boost::any or some other "common denominator" as a frequent use case.
So what will deducing that type from the function object buy us?
The only answer I can currently see is "nothing but trouble" :-). Please tell me if I'm missing something.
From what I can see, it buys simplicity when the use case is not complicated (the return type is available through result_type or result_of and does not change), or when you really want to leave it to
the function object to specify what the return type should be. Granted, all of the proposed solutions for return type deduction seem slightly imperfect / inelegant, but as long as the behavior is clearly explained in the documentation they could be useful. Regards, Stjepan
Stjepan Rajko wrote:
On Jan 6, 2008 12:20 PM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
So what will deducing that type from the function object buy us?
The only answer I can currently see is "nothing but trouble" :-). Please tell me if I'm missing something.
From what I can see, it buys simplicity when the use case is not complicated (the return type is available through result_type or result_of and does not change), or when you really want to leave it to the function object to specify what the return type should be.
(-: Please excuse my forthright bluntness: 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). The latter seems to me as a misguided approach that encourages users to mess up the result type computation of their function objects. A user framework might still define its own Concept picking a custom type member (that will typically be one that does not interfere with those looked at by result_of) where appropriate.
Granted, all of the proposed solutions for return type deduction seem slightly imperfect / inelegant, but as long as the behavior is clearly explained in the documentation they could be useful.
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. Regards, Tobias
On Jan 7, 2008 2:55 AM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
Stjepan Rajko wrote:
On Jan 6, 2008 12:20 PM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
So what will deducing that type from the function object buy us?
The only answer I can currently see is "nothing but trouble" :-). Please tell me if I'm missing something.
From what I can see, it buys simplicity when the use case is not complicated (the return type is available through result_type or result_of and does not change), or when you really want to leave it to the function object to specify what the return type should be.
(-: Please excuse my forthright bluntness:
I welcome forthright bluntness :-)
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).
The latter seems to me as a misguided approach that encourages users to mess up the result type computation of their function objects.
A user framework might still define its own Concept picking a custom type member (that will typically be one that does not interfere with those looked at by result_of) where appropriate.
Granted, all of the proposed solutions for return type deduction seem slightly imperfect / inelegant, but as long as the behavior is clearly explained in the documentation they could be useful.
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 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!). Regards, Stjepan
participants (2)
-
Stjepan Rajko -
Tobias Schwinger