On Mar 27, 2012, at 4:55 PM, Eric Niebler wrote:
On 3/27/2012 1:10 PM, Nathan Ridge wrote:
Date: Tue, 27 Mar 2012 13:00:19 -0700 From: eric@boostpro.com To: daniel.j.walker@gmail.com CC: boost@lists.boost.org Subject: Re: [boost] [result_of] Make `cpp0x_result_of_impl` public
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?
Why not implement boost::result_of using decltype only on compilers that have N3256 decltype, and give users with compilers that have non-N3256 decltype the option of turning on BOOST_RESULT_OF_USE_DECLTYPE?
I think Nate's suggestion is reasonable. Boost libraries which require N3256 can use tr1::result_of, so that they are more portable to non-standard compilers and do not break as easily when users request decltype-based boost::result_of, which, of course, is a perfectly reasonable request.
Because BOOST_RESULT_OF_USE_DECLTYPE is a big hammer, and if someone uses that hammer with a non-N3256 compiler, there will be much collateral damage. Innocent bystanders. Think of the children.
boost::result_of can guarantee backwards compatibility with TR1 in situations where the TR1 result_of protocol was used to generate the type of the given call-expression. If the TR1 protocol was used to generate an incomplete type, then boost::result_of can't make that guarantee on non-N3256 compliant compilers. I think most users would find this completely acceptable. - Daniel