Allow result_of to fall back on decltype

[nathan.crookston+boost@…]

result_of uses decltype by default on very few compilers, since most current compilers' decltype support doesn't work for some TR1-style usage.

Many of those same compilers support C++11 lambdas which don't follow TR1 result_of protocol. Currently, this makes lambdas very difficult to use with other code using result_of.

The attached code allows compilers which partially support decltype to use it only on functors which don't publish a result_type or result struct.

It also contains tests & doc changes. Compiled with VC10, clang++3.1 & g++4.5 (both compilers with and without -std=c++0x).

[Michel Morin]

Patch by Nathan Crookston

[Michel Morin]

Attached a patch by Nathan Crookston

[Daniel Walker]

Currently, result_of has two "modes" of operation: TR1 mode and decltype mode. Users can select the mode via the BOOST_RESULT_OF_USE_TR1 and BOOST_RESULT_OF_USE_DECLTYPE macros. You are proposing a third mode, a hybrid mode, in which result_of would operate in TR1 or decltype mode depending on whether or not the function object employs the TR1 protocol. The hybrid mode would be appealing to projects that sometimes require full decltype support (e.g. using result_of with incomplete return types) and sometimes do not (e.g. using result_of with C++11 lambdas). The hybrid mode would allow users to selectively employ the TR1 protocol to workaround deficiencies in their compiler's decltype support. Such workarounds are already possible, however, in user code (e.g. defining BOOST_RESULT_OF_USE_DECLTYPE while routing legacy TR1 code to boost::tr1::result_of<>), though these user-level workarounds could be cumbersome in some situations.

The proposal may have some merit, but it also has some costs. My immediate inclination is to leave things as they are for two reasons: 1) usually decltype is a good alternative to the TR1 protocol even on compilers where it is not fully supported, in which case there are already workarounds for the corner cases; 2) two result_of modes are simpler than three. However, I would suggest that you start a thread on the Boost developer mailing list to discuss your proposal and solicit the thoughts of others.

[nathan.crookston+boost@…]

Thanks, Daniel. This patch was actually created in response to a thread:

​http://boost.2283326.n4.nabble.com/Range-amp-c-0x-Lambdas-Can-this-be-done-td4638947.html

I would be concerned about using a non-industrial strength decltype on a whole project basis (e.g., if my project used Proto, which requries N3276), and concerned about enabling decltype on a translation unit-by-translation unit basis (potential ODR problems).

[Nathan Crookston <nathan.crookston+boost@…>]

Updated to use _CXX11_ style macros.

[Daniel Walker]

(In [84949]) added new result_of mode that uses TR1 with a decltype fallback as suggested by Nathan Crookston; fixes #7753