On Tue, Sep 4, 2012 at 7:32 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
On Tue, Sep 4, 2012 at 7:00 PM, Joel de Guzman <djowel@gmail.com> 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@gmail.com> 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