On Tue, May 31, 2011 at 9:37 PM, Michel MORIN <mimomorin@gmail.com> wrote:

Daniel Walker wrote:

...

At some point, BOOST_RESULT_OF_USE_DECLTYPE may be defined by default, probably when there's enough user interest, so thanks for cc'ing me. The reason it is currently not defined by default is that it is possible that it could introduce breaking changes to some C++03 function objects; e.g. if a function object defines result_type to be some type other than the type of a call expression, then in C++03 result_of would give the user-specified result_type rather than the actual result type, whereas in C++0x result_of always gives the actual result type. For example:

#include <boost/type_traits.hpp> #include <boost/utility/result_of.hpp>

struct f {    typedef int result_type;    double operator()(double); };

int main() {    using namespace boost;    typedef result_of<f(double)>::type type; #ifdef BOOST_RESULT_OF_USE_DECLTYPE    static_assert(is_same<type, double>::value, ""); #else    static_assert(is_same<type, int>::value, ""); #endif }

Thank you for explaining the problem. And yes, backward compatibility is always problematic.

IMO, this use case is not the intended use of boost::result_of, so is it reasonable to deprecate this?

This is not an intended (or supported) use case at all. Nevertheless, it seemed reasonable to roll out decltype slowly.

And how about adding a "Note" that warns this kind of codes will break in the future to the documentation?

Sure. I added the following: "In a future release, BOOST_RESULT_OF_USE_DECLTYPE may be enabled by default on compilers that support decltype, so if you use the above protocol please take care to ensure that the result_type and result<> members are accurate. If you wish to continue to use the protocol on compilers that support decltype, use boost::tr1_result_of, which is also defined in <boost/utility/result_of.hpp>." Thanks for the suggestions! Daniel Walker