Boost C++ Libraries: Ticket #7753: Allow result_of to fall back on decltype

attachment set

Michel Morin — Sat, 01 Dec 2012 10:35:47 GMT

attachment → result_of.diff

Patch by Nathan Crookston

Michel Morin — Sat, 01 Dec 2012 10:36:20 GMT

Attached a patch by Nathan Crookston

Daniel Walker — Sat, 01 Dec 2012 17:43:05 GMT

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@… — Sat, 01 Dec 2012 18:01:42 GMT

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).

attachment set

Wed, 10 Apr 2013 17:17:19 GMT

attachment → result_of.patch

Updated to use _CXX11_ style macros.

status changed; resolution set

Daniel Walker — Wed, 03 Jul 2013 22:14:28 GMT

status new → closed
resolution → fixed

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