On Jun 21, 2013, at 4:23 PM, Nathan Crookston
Hi Eric,
Eric Niebler wrote:
On 6/19/2013 10:59 PM, Nathan Crookston wrote:
Of course, I'd rather have BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK defined automatically for compilers like VC10, g++4.5, etc.
So, why not? I haven't been following the discussion recently, but I seem to recall that we agreed to this at some point.
Daniel looked over the patch and suggested it would be best not to define the fallback mode by default. Here's the thread:
http://lists.boost.org/Archives/boost/2013/04/202629.php
I said I'd make a patch which follows his suggestion, but that I'd try to convince him to accept the first patch. I'll reiterate, I think it would be more surprising to have boost::result_of not work with compiler-supported lambdas than to have it correctly deduce results that would have been erroneous using TR1. Even though VC10's std::result_of didn't work with them either (for example).
I am disinclined to make an unannounced change in the default behavior. If we made any change in the default, since we have already announced that we are rolling out a purely decltype-based implementation, I would prefer to loosen the N3276 requirement and simple use decltype when BOOST_HAS_DECLTYPE is defined. This would probably be less confusing to new users who seem to expect boost::result_of to act like std::result_of out of the box. However, I still like the idea of having a separate hybrid mode that would work with legacy protocols when available. (It occurred to me that this same idea has come up in the past with respect to Boost.Lambda's sig<> protocol, and it would be really cool to support both TR1 and sig<> in the hybrid mode.) - Daniel