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@gmail.com> 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; The reason it works is that TR1 result_of does not attempt the match the argument types on invalid (substitution failure) overload selection.
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.
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.
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. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com