[boost] Re: Re: function (object) return and argument metafunctions?

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2004-02-08 17:15:32

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