Re: [boost] [result_of] now uses decltype on release branch

Subject: Re: [boost] [result_of] now uses decltype on release branch
From: Joel de Guzman (djowel_at_[hidden])
Date: 2012-09-04 20:01:25

On 9/5/2012 12:53 AM, Michel Morin wrote:

> Joel de Guzman wrote:
>> However! This makes the current result_of code not an exact replacement
>> to decltype which allows this variation of above:
>
> Right. boost/std::result_of is not an exact replacement to decltype,
> since decltype allows SFINAE but boost/std::result_of doesn't.
>
> [...]
>> If Fusion's invoke used decltype instead of
>> result_of, it would have worked.
>
> I tried to compile my test case for fusion::invoke with SFINAE-enabled
> result_of, but it failed to compile. After adding a "fallback type" to
> SFINAE-enabled result_of, then the test case runs fine.

The following code (attached) demonstrates the problem of
Fusion::invoke with the current decltype based result_of. Comment
out the first line for the code to use plain decltype vs. result_of.
Notice that because result_of does not allow SFINAE, it barfs when
the compiler tries the first overload of invoke (substitution failure).
The compiler could have chosen the second overload.

I see no other way to get around this problem of result_of. I am
getting inclined to use decltype directly in fusion instead of
going through result_of. Problems like this kinda defeats the
purpose of decltype-ifying result_of, but heck.

The question is: should we allow SFINAE for result_of. I think now
that we should.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com