Vicente J. Botet Escriba wrote:
We should proceed gradually even if N3276-decltype is available, because * decltype-based result_of can break user codes with (unintended) use of result_of. * Implementation of N3276-decltype might be buggy for some time.
Thanks for the clarification. So if IUC, the use of BOOST_RESULT_OF_USE_DECLTYPE in the user code could break other parts of her application, isn't it?
Right. There are two types of breakage. (But note that the correct support of the traditional result_of protocol and the correct usage of result_of should not make any breakage with BOOST_RESULT_OF_USE_DECLTYPE + N3276-decltype. So, I think, you don't have to worry about the breakage too much.) 1) Breakage caused by type-completeness requirement of non-N3276-decltype Boost.Proto uses boost::tr1_result_of to avoid this problem. boost::tr1_result_of uses the traditional implementation of result_of even if BOOST_RESULT_OF_USE_DECLTYPE is defined. 2) Breakage caused by incorrect support or incorrect usage of result_of Some codes using Boost.Fusion or Boost.Phoenix fail to compile if BOOST_RESULT_OF_USE_DECLTYPE is defined. http://thread.gmane.org/gmane.comp.parsers.spirit.general/24027 https://svn.boost.org/trac/boost/ticket/5687 Regards, Michel