On 9/3/2012 12:07 PM, Joel de Guzman wrote:
On 9/3/2012 11:10 AM, Michel Morin wrote:
Joel, Fusion's invoke test (libs/fusion/test/invoke.test) fails with decltype-based result_of.
The reason of the test failure is that fusion::invoke tries to instantiate boost::result_of with uncallable signatures. (Just making boost::result_of SFINAE-able does not solve the problem.)
Here is a minimal test case: [snip]
And here is a related ticket https://svn.boost.org/trac/boost/ticket/6915
Ok I fixed the fusion::invoke test. Tricky! That also fixes the first test from Ticket #6915. The second, OTOH, I think is an error. Essentially, what the OP wants is something like this to work (i.e. compile and call the fallback overload): #include <boost/utility/result_of.hpp> int foo(int); struct junk {}; template <typename F, typename Arg> typename boost::result_of<F(Arg)>::type call(int) { return F(Arg()); } template <typename F, typename Arg> void call(long) { // fallback } int main() { call<int(*)(int), junk>(123); } And so you get: error: cannot convert 'junk' to 'int' in argument passing That IMO is the correct behavior. If not, then boost::result_of is wrong. However! This makes the current result_of code not an exact replacement to decltype which allows this variation of above: #include <boost/utility/result_of.hpp> int foo(int); struct junk {}; template <typename F, typename Arg> decltype(F(Arg())) call(int) { return F(Arg()); } template <typename F, typename Arg> void call(long) { // fallback } int main() { call<int(*)(int), junk>(123); } So, there's your problem. If Fusion's invoke used decltype instead of result_of, it would have worked. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com