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:32:57

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:
>>
>>  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.
>>
>
> Wrong. TR1 result-of works with function objects. See attached. It works
> with both nested result_type and struct result;
>

Eh, that's why I said, "properly restricted". Replace the result
specialization with anything that disallows the erroneous binding and it
fails. E.g.,

template< class This > struct result< This ( int & ) > { typedef int type;
};

By the way, your given specialization of result,

template <typename T> struct result<foo(T&)> { typedef int type; };

is not correct. It will fail for result_of< F const ( Arg& ) >::type
(should one decide to use a const-qualified function object), even though
this is a valid call signature.

In any case, I still think your use of result_of in the given example was
brittle and, ultimately, a misuse, whether we're speaking of the TR1-based
or the decltype-based result_of. AFAIK, result_of has never had any
guarantees as far as instantiating it with invalid call signatures.

The reason it works is that TR1 result_of does not attempt the
> match the argument types on invalid (substitution failure) overload
> selection.
>

But, it could, and more importantly, there's certainly no guarantee that it
*won't*, either directly within the result_of implementation or implicitly
by virtue of the available result specializations.

 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 don't know. All I am saying is that this poses real problems
> that go beyond correct usage of result_of. I do not have time
> to look through all the posts in this thread.
>

See (*) above, which you quoted :/

 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?

 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?
>>
>
> I don't know. I will not have enough time to follow through with this
> anyway
> so I'll leave it to the result_of people to "do the right thing". In any
> case, I can work out a solution/workaround.
>

You can't just make a proposal and then crawl back in your cave :)

- Jeff