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

Subject: Re: [boost] [result_of] now uses decltype on release branch
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-09-04 21:03:07

On Tue, Sep 4, 2012 at 5:01 PM, Joel de Guzman <djowel_at_[hidden]> wrote:

> 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.

It seems like the fact that it worked with the TR1-protocol-based result_of
was brittle at best. Replace foo with a function object with a properly
restricted result template and it likely wouldn't work with
TR1-protocol-based result_of, either.

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.
>

Wasn't this fact (the difference between result_of and decltype) already
pointed out earlier in this thread?

> 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.
>

Is this a recently discovered problem with the use of result_of in Fusion?
How come it didn't come up before?

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

Wouldn't this create a portability problem between C++03 and C++11? Or are
you suggesting this for C++11-only code? Or are you suggesting to likewise
modify result_of in C++03 to allow SFINAE, via something like Eric's
can_be_called metafunction?

- Jeff