Re: [boost] [result_of] Make `cpp0x_result_of_impl` public

Subject: Re: [boost] [result_of] Make `cpp0x_result_of_impl` public
From: Eric Niebler (eric_at_[hidden])
Date: 2012-03-27 14:53:51

On 3/27/2012 11:49 AM, Daniel Walker wrote:
> 
> On Mar 27, 2012, at 1:35 PM, Eric Niebler wrote:
> 
>> On 3/24/2012 1:52 AM, Michel Morin wrote:
>>> There are two implementations of boost::result_of: a TR1-style
>>> implementation and a decltype-based implementation. While
>>> the TR1-style implementation has a public interface `boost::tr1_result_of`,
>>> decltype-based one doesn't have a public interface.
>>
>> Yes, I'm the one responsible for this change.
>>
>>> By defining BOOST_RESULT_OF_USE_DECLTYPE,
>>> boost::result_of use decltype-based implementation.
>>> But this is not always a viable solution, since this breaks
>>> some Boost libraries.
>>>
>>> So how about adding `boost::cxx11_result_of` as public interface
>>> of the decltype-based implementation?
>>> Attached a patch to add `boost::cxx11_result_of`.
>>> (This patch also changes the name of `cpp0x_result_of_impl`
>>> to `cxx11_result_of_impl` to reflect the recent discussion on
>>> the cpp/cxx naming.)
>>
>> The patch looks fine, and I guess I'm as qualified to apply it as
>> anybody. But it doesn't have docs and tests. Care to address that? The
>> docs probably only need a line or two, and you can copy the tests for
>> tr1_result_of.
>>
> 
> I'm not sure that I agree that cxx11_result_of is a good idea. The plan was for boost::result_of to become a C++11 result_of as soon as we're comfortable flicking the switch so that it's on by default (on platforms that can support it). Michel, do you just want a C++11 result_of that works out-of-the-box or do you really need a separate interface in addition to boost::result_of?

There are places where a decltype-based result_of is safe, even if N3256
isn't implemented. In that case, cxx11_result_of would be the only
option, since boost::result_of would still defer to tr1_result_of.

>>> P.S.
>>> Is it worth trying to use this `boost::cxx11_result_of`
>>> in `boost::transform_iterator` code on trunk?
>>
>> Now that we have a macro to detect compliance with N3256, we have a way
>> to safely enable decltype-based result_of by default. We should think
>> about doing that and fixing the bugs this will flush out. This should be
>> a separate step, though, and it should be done very early in a release
>> cycle.
> 
> Good idea.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com