Re: [Boost-bugs] [Boost C++ Libraries] #7753: Allow result_of to fall back on decltype

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7753: Allow result_of to fall back on decltype
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-12-01 17:43:05

#7753: Allow result_of to fall back on decltype
-----------------------------------------------+----------------------------
  Reporter:  nathan.crookston+boost@…          |       Owner:  djwalker 
      Type:  Feature Requests                  |      Status:  new      
 Milestone:  To Be Determined                  |   Component:  result_of
   Version:  Boost Development Trunk           |    Severity:  Problem  
Resolution:                                    |    Keywords:           
-----------------------------------------------+----------------------------

Comment (by djwalker):

 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7753#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.