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 22:41:42

On Tue, Sep 4, 2012 at 7:32 PM, Jeffrey Lee Hellrung, Jr. <
jeffrey.hellrung_at_[hidden]> wrote:

> On Tue, Sep 4, 2012 at 7:00 PM, Joel de Guzman <djowel_at_[hidden]> wrote:
>
>> On 9/5/2012 9:03 AM, Jeffrey Lee Hellrung, Jr. wrote:
>>
>>> On Tue, Sep 4, 2012 at 5:01 PM, Joel de Guzman <djowel_at_[hidden]> wrote:
>>>
>>> [...]

> 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.
>>>>
>>>>
>>> Is this a recently discovered problem with the use of result_of in
>>> Fusion?
>>>
>>
>> Yes.
>>
>>  How come it didn't come up before?
>>>
>>
>> Because BOOST_RESULT_OF_USE_DECLTYPE wasn't there before.
>>
>
> May we inspect a typical use of result_of that was working before and
> isn't now?
>

Actually, upon thinking about the larger context, I see where this could
easily happen (sorry for being dense, Joel)...
- I'm surprised it didn't fail TR1-based result_of more often :/
- I don't know how to fix it for TR1-based result_of except using something
like Eric's can_be_called metafunction.

- Jeff