Re: [boost] [Boost-users] upcoming Switch library review Jan 5th - Jan 9th

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-07 04:55:09

Stjepan Rajko wrote:
> On Jan 6, 2008 12:20 PM, Tobias Schwinger <tschwinger_at_[hidden]> 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