[result_of, tr1] use of decltype in boost::result_of breaks <boost/tr1/functional.hpp>

[Eric Niebler]

Boost.TR1 is supposed to provide an implementation of TR1's library functionality. The change to boost::result_of on truck to use decltype on supporting compilers makes Boost.TR1's implementation of std::tr1::result_of non-compliant, as evidenced by the recent Boost.TR1 regression test failures on c++0x toolsets. It also breaks Proto because there is a bug in the specification of decltype that causes code that is valid with TR1 result_of to break with the c++0x result_of.

The attached patch fixes the issue with boost::result_of and <boost/tr1/functional.hpp>. It adds a new template in <boost/utility/result_of.hpp> called tr1_result_of that implements the TR1 result_of protocol regardless of whether decltype is available or not. It also changes <boost/tr1/functional.hpp> to define std::tr1::result_of in terms of boost::tr1_result_of.

[Eric Niebler]

updated attachment that puts the decltype implementation on a switch BOOST_RESULT_OF_USE_DECLTYPE

[Eric Niebler]

I've changed the patch so that boost::result_of only uses the decltype implementation if BOOST_RESULT_OF_USE_DECLTYPE is defined. This is a safer change that allows users to opt in to the brave new c++0x world without breaking users who aren't prepared to make that leap.

[Eric Niebler]

patch committed in changeset [61248]