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

Subject: Re: [boost] [result_of] Make `cpp0x_result_of_impl` public
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2012-03-27 18:35:39

On Mar 27, 2012, at 4:00 PM, Eric Niebler wrote:

> On 3/27/2012 12:48 PM, Daniel Walker wrote:
>> 
>> On Mar 27, 2012, at 2:53 PM, Eric Niebler wrote:
>> 
>>> 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.
>> 
>> I would prefer, rather than fracturing the API, that we provide decltype-based boost::result_of by default on compilers that provide a reasonable decltype implementation, even if it's not fully N3256 compliant, with a well-documented caveat that boost::result_of depends on the compiler's decltype. For those who would rather have TR1 result_of than a result_of using non-N3256 decltype, they can use the existing tr1::result_of or boost::tr1_result_of.
> 
> This will badly and needlessly break valid code both within boost and in
> the wild for a large segment of Boost's users. Why would you prefer
> doing that than taking the safer course?

I am not convinced that the absence of N3256 will break much code. It would be interesting to see how many Boost libraries actually require N3256. It wouldn't be hard to run the entire test suite using the decltype-based boost::result_of. We just need a volunteer to run the experiment. :-) Michel?

Of course, libraries that do require N3256 could workaround non-compliant compilers by using tr1::result_of, for example. 

- Daniel