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