|
Boost : |
Subject: Re: [boost] [result_of] Documentation update for ticket 7753
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2013-06-21 20:20:52
On Jun 21, 2013, at 4:23 PM, Nathan Crookston <nathan.crookston_at_[hidden]> wrote:
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk