Brian McNamara wrote:
On Sun, Feb 08, 2004 at 09:04:11PM +0100, Fredrik Blomqvist wrote:
What I want to add to the discussion is that I believe we need _two_ versions of return_type (or whatever we choose to call it). Even though I like the power and syntax of the result_of<F(a,b)>, I'd say it's not unreasonable to be in a situation where the argument types (if any) simply aren't know. In such cases a plain return_type<F> that would atleast make an "educated guess" would be better than nothing.
Here you go:
template <class F> struct educated_guess_return_type { typedef int result_type; };
It is right every time the actual return type is "int"! :)
Seriously, can you show a case how "educated guess" is better than nothing? My instincts tell me that it's better to fail to compile than to guess the wrong type and start having random implicit conversions start kicking in.
Re-reading my previous post I can see I was unclear. I'm Not advocating a solution that would never fail! What I carelessly referred to by "educated guess" was to use the "old" pre result_of techniques in the non argument-type version. Basically piecing together function_traits<>, member_function_traits<> and lastly a fallback to ::result_type. That technique doesn't require argument types but would still cover many common cases. result_of may simply succeed with deduction when this technique fails.
In the (rare?) case where the return type of F doesn't depend on its arguments, then it either (a) it should probably just declare an F::result_type (in which case I think result_of<F> may work), or The result_of implementation in the sandbox doesn't seem to do that (it always requires the call syntax). But if it is possible that would be great of course.
Regards // Fredrik Blomqvist