[result_of] Make `cpp0x_result_of_impl` public
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. 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.) P.S. Is it worth trying to use this `boost::cxx11_result_of` in `boost::transform_iterator` code on trunk? Regards, Michel
Nathan Ridge wrote:
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.
Perhaps we could fix those instead?
Without N3256 decltype (which does not require type completeness in function call expressions), some problems cannot be avoided. For this reason, Boost.Proto explicitly uses tr1_result_of. For other reasons, I think we could fix them. We should perform regression tests with BOOST_RESULT_OF_USE_DECLTYPE for the clients of result_of. Regards, Michel
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.
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. -- Eric Niebler BoostPro Computing http://www.boostpro.com
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?
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. - Daniel
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
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. - Daniel
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? -- Eric Niebler BoostPro Computing http://www.boostpro.com
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? Regards, Nate
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?
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. -- Eric Niebler BoostPro Computing http://www.boostpro.com
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
On 3/27/2012 4:13 PM, Daniel Walker wrote:
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.
I should say that Nate's suggestion *is* reasonable, but (IIUC) he's not suggesting turning on decltype-based result_of for non-N3256 compilers, as you are (right?). His suggestion is pretty much The Plan and has been all along. He's merely questioning the need for an additional cxx11_result_of. I think it has value for people with who want to selectively use decltype-based result_of in their code where they know it is safe, regardless of whether a compiler implements N3256. But now that I rethink this, the use of cxx11_result_of anywhere necessarily makes such code non-portable to c++03 compilers, so it'll probably never be used within Boost. It could only be used (a) by Boost's users who (b) have compilers that support decltype and (c) don't support N3256 and (d) don't have a std::result_of that uses decltype. I'm pretty sure that's exactly zero people. So I'm flip-flopping. Nate's suggestion is correct. As for your suggestion that Boost libraries can use tr1_result_of where necessary, I agree. Proto already does this.
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.
Again, I ask why? Why, when there is a less risky path forward? When we specifically added a feature test for compliance with N3256 for this very purpose? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Mar 27, 2012, at 8:28 PM, Eric Niebler wrote:
On 3/27/2012 4:13 PM, Daniel Walker wrote:
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.
I should say that Nate's suggestion *is* reasonable, but (IIUC) he's not suggesting turning on decltype-based result_of for non-N3256 compilers, as you are (right?). His suggestion is pretty much The Plan and has been all along. He's merely questioning the need for an additional cxx11_result_of. I think it has value for people with who want to selectively use decltype-based result_of in their code where they know it is safe, regardless of whether a compiler implements N3256.
That's right. Nate pretty much restated the plan. In considering alternatives, I don't mean to suggest that we should actually veer from the plan. :-) It still seems the best course of action to enable it by default only when N3256 is available.
But now that I rethink this, the use of cxx11_result_of anywhere necessarily makes such code non-portable to c++03 compilers, so it'll probably never be used within Boost. It could only be used (a) by Boost's users who (b) have compilers that support decltype and (c) don't support N3256 and (d) don't have a std::result_of that uses decltype. I'm pretty sure that's exactly zero people.
So I'm flip-flopping. Nate's suggestion is correct.
As for your suggestion that Boost libraries can use tr1_result_of where necessary, I agree. Proto already does this.
Good. OK, I think we're on the same page.
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.
Again, I ask why? Why, when there is a less risky path forward? When we specifically added a feature test for compliance with N3256 for this very purpose?
It's really nice to have a feature test for this. Thanks! While I think it would be acceptable to release a decltype-based result_of on non-N3256 compilers, assuming the impact on boost libraries was minimal and easily correctable, I don't think it's necessary. Hopefully, things are moving quickly enough on the compiler front that N3256 will be widely implement and this whole discussion will be moot. - Daniel
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.
I should say that Nate's suggestion *is* reasonable, but (IIUC) he's not suggesting turning on decltype-based result_of for non-N3256 compilers, as you are (right?).
(By the way, as I just realized after a search for "N3256" turned up an unrelated paper, it's N3276, not N3256). You are right, I was not suggesting turning on decltype-based result_of for non-N3276 compilers by default. People with non-N3276 compilers can choose to turn on decltype-based result_of with BOOST_RESULT_OF_USE_DECLTYPE.
His suggestion is pretty much The Plan and has been all along. He's merely questioning the need for an additional cxx11_result_of. I think it has value for people with who want to selectively use decltype-based result_of in their code where they know it is safe, regardless of whether a compiler implements N3256.
But now that I rethink this, the use of cxx11_result_of anywhere necessarily makes such code non-portable to c++03 compilers, so it'll probably never be used within Boost. It could only be used (a) by Boost's users who (b) have compilers that support decltype and (c) don't support N3256 and (d) don't have a std::result_of that uses decltype. I'm pretty sure that's exactly zero people.
One could write a result_of_for_complete_types_only (with a better name of course :) ) that is implemented using decltype on all C++11 compilers (including non-N3276), and using the TR1 protocol on others. This would then be backward-compatible to C++03, and Boost could use it in some places. I have been using a non-N3276 C++11 compiler, and turning on BOOST_RESULT_OF_USE_DECLTYPE, for about a year now, and I haven't run into a situation where I need N3276. The advantage of such a "result_of_for_complete_types_only" for someone like me would be that if I ever do run into a situation like that, and my compiler still does not support N3276 at that point, so I need to turn BOOST_RESULT_OF_USE_DECLTYPE *off*, then I wouldn't need to implement the result_of protocol for *all* my function objects, only *some* (the ones used by Boost features that use result_of rather than result_of_for_complete_types_only). That seems like a fairly small advantage to me, for which Boost maintains would have to do a fair bit of work, which is why I'm suggesting not to bother with it. Regards, Nate
Boost's users who (b) have compilers that support decltype and (c) don't support N3256 and (d) don't have a std::result_of that uses decltype. I'm pretty sure that's exactly zero people.
Right! Forgot about std::result_of. (Though gcc-4.4 supports decltype and does not provide decltype-based std::result_of, gcc-4.4 is old and no longer maintained release series.) Regards, Michel
[Michel Morin]
Boost's users who (b) have compilers that support decltype and (c) don't support N3256 and (d) don't have a std::result_of that uses decltype. I'm pretty sure that's exactly zero people.
Right! Forgot about std::result_of.
(Though gcc-4.4 supports decltype and does not provide decltype-based std::result_of, gcc-4.4 is old and no longer maintained release series.)
Sorry, I haven't been following this thread, but VC10 has decltype v1.0 (not v1.1) and its std::result_of follows the TR1 protocol (not decltype-powered). Is that of interest? (VC11 has decltype v1.1 and its std::result_of is decltype-powered.) STL
On 3/27/2012 6:38 PM, Stephan T. Lavavej wrote:
[Michel Morin]
Boost's users who (b) have compilers that support decltype and (c) don't support N3256 and (d) don't have a std::result_of that uses decltype. I'm pretty sure that's exactly zero people.
Right! Forgot about std::result_of.
(Though gcc-4.4 supports decltype and does not provide decltype-based std::result_of, gcc-4.4 is old and no longer maintained release series.)
Sorry, I haven't been following this thread, but VC10 has decltype v1.0 (not v1.1) and its std::result_of follows the TR1 protocol (not decltype-powered). Is that of interest?
(VC11 has decltype v1.1 and its std::result_of is decltype-powered.)
Thanks, Stephan. That makes the picture murkier. So do we add cxx11_result_of, support it, doc it and test it indefinitely, for the sake of the users of one version of one compiler? <sigh!> I, for one, would rather spend my energy elsewhere. Like making boost::result_of use decltype by default on compliant compilers. Which I hope to do on trunk in the very near future. Any objections to this plan? -- Eric Niebler BoostPro Computing http://www.boostpro.com
[STL]
Sorry, I haven't been following this thread, but VC10 has decltype v1.0 (not v1.1) and its std::result_of follows the TR1 protocol (not decltype-powered). Is that of interest?
(VC11 has decltype v1.1 and its std::result_of is decltype-powered.)
[Eric Niebler]
Thanks, Stephan. That makes the picture murkier. So do we add cxx11_result_of, support it, doc it and test it indefinitely, for the sake of the users of one version of one compiler? <sigh!>
Occasionally, users (correctly) complain that VC10's result_of doesn't work with lambdas (which don't provide result_type). Users who keep using VC10, for whatever reason, after VC11 is released may want a decltype-powered alternative. However, this usually comes up when they're trying to bind() a lambda, which isn't an especially compelling scenario. It's better to write a lambda that effectively binds arguments itself. (In fact, I would have preferred to deprecate bind() in C++11.) Some users writing highly generic code may have a stronger need for a decltype-powered result_of - but these are precisely the kind of users that would be affected by decltype v1.0. STL
"Stephan T. Lavavej" <stl@exchange.microsoft.com> writes:
[STL]
Sorry, I haven't been following this thread, but VC10 has decltype v1.0 (not v1.1) and its std::result_of follows the TR1 protocol (not decltype-powered). Is that of interest?
(VC11 has decltype v1.1 and its std::result_of is decltype-powered.)
[Eric Niebler]
Thanks, Stephan. That makes the picture murkier. So do we add cxx11_result_of, support it, doc it and test it indefinitely, for the sake of the users of one version of one compiler? <sigh!>
Although this makes it more of a compelling use case. Given that the picture is really grim. We have compilers that implement a * fully conforming result_of * result_of with a broken decltype * result_of without decltype My current approach has been to fall back on std::result_of if I want to provide support for lambdas in my code and need to forward them (and if the compiler supports them) and otherwise fall back to boost::result_of. Compilers that support lambdas but not a working std::result_of make this seem dubious and the correct implementation with full support for everything would be do check for a conforming decltype, a C++11 result_of and lambda support and bring all this together to pick the right version. This seems a lot of pain for something that hopefully will go away, but it would be nice if I had some library support to write code like that. ;) Philipp Moeller
On Mar 27, 2012, at 11:45 PM, Eric Niebler wrote:
On 3/27/2012 6:38 PM, Stephan T. Lavavej wrote:
[Michel Morin]
Boost's users who (b) have compilers that support decltype and (c) don't support N3256 and (d) don't have a std::result_of that uses decltype. I'm pretty sure that's exactly zero people.
Right! Forgot about std::result_of.
(Though gcc-4.4 supports decltype and does not provide decltype-based std::result_of, gcc-4.4 is old and no longer maintained release series.)
Sorry, I haven't been following this thread, but VC10 has decltype v1.0 (not v1.1) and its std::result_of follows the TR1 protocol (not decltype-powered). Is that of interest?
(VC11 has decltype v1.1 and its std::result_of is decltype-powered.)
Thanks, Stephan. That makes the picture murkier. So do we add cxx11_result_of, support it, doc it and test it indefinitely, for the sake of the users of one version of one compiler? <sigh!>
I, for one, would rather spend my energy elsewhere. Like making boost::result_of use decltype by default on compliant compilers. Which I hope to do on trunk in the very near future.
Any objections to this plan?
Nope. Sounds good to me! Let me know if you want any help. - Daniel
On 3/28/2012 3:54 PM, Daniel Walker wrote:
On Mar 27, 2012, at 11:45 PM, Eric Niebler wrote: <snip>
I, for one, would rather spend my energy elsewhere. Like making boost::result_of use decltype by default on compliant compilers. Which I hope to do on trunk in the very near future.
Any objections to this plan?
Nope. Sounds good to me! Let me know if you want any help.
OK, this is now implemented on trunk as of [77905]. I don't know of a compiler that implements N3276 so I wasn't able to test it as thoroughly as I would have liked, but bang! it's in there. Would love if someone else could take a look and see if I missed anything obvious. https://svn.boost.org/trac/boost/changeset/77905 -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
OK, this is now implemented on trunk as of [77905]. I don't know of a compiler that implements N3276 so I wasn't able to test it as thoroughly as I would have liked, but bang! it's in there. Would love if someone else could take a look and see if I missed anything obvious.
I ran the test of result_of on clang trunk (which implements N3276 decltype). The results are fine (except cv-qualification issue I posted in another thread). I also tested Proto and all the tests ran successfully. There are two test runners with clang trunk (i.e. "Sandia-clang-trunk" and "Sandia-darwin-clang-trunk"), but they seem to be a bit old; they don't seem to have N3276 decltype. Regards, Michel
On 4/13/2012 7:34 AM, Michel Morin wrote:
Eric Niebler wrote:
OK, this is now implemented on trunk as of [77905]. I don't know of a compiler that implements N3276 so I wasn't able to test it as thoroughly as I would have liked, but bang! it's in there. Would love if someone else could take a look and see if I missed anything obvious.
I ran the test of result_of on clang trunk (which implements N3276 decltype). The results are fine (except cv-qualification issue I posted in another thread). I also tested Proto and all the tests ran successfully.
Did you update Boost.Config to unset BOOST_NO_DECLTYPE_N3276 for recent clang builds? If not, you really weren't testing a decltype-based result_of.
There are two test runners with clang trunk (i.e. "Sandia-clang-trunk" and "Sandia-darwin-clang-trunk"), but they seem to be a bit old; they don't seem to have N3276 decltype.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
I ran the test of result_of on clang trunk (which implements N3276 decltype). The results are fine (except cv-qualification issue I posted in another thread). I also tested Proto and all the tests ran successfully.
Did you update Boost.Config to unset BOOST_NO_DECLTYPE_N3276 for recent clang builds?
Sure. (It was me that updated Boost.Config's clang.hpp on trunk :) )
If not, you really weren't testing a decltype-based result_of.
Regards, Michel
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?
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.
Why not use both the result_of protocol and decltype? So, 1) detect for the template result 2) check for the type result_type 3) use decltype Also, on compilers that don't support sfinae for expressions, it could also detect the callability of the function using the same techniques in Boost.Proto. This way, result_of<>::type is only valid when the call is valid. Furthermore, the third step could be emulated on C++03 compilers using Boost.TypeOf and rvalue detection techniques used in Boost.Foreach. Thanks, Paul Fultz II
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
Daniel Walker wrote:
It would be interesting to see how many Boost libraries actually require N3256.
Nathan Ridge and I made some efforts to test compatibility with decltype-based result_of. All the incompatibilities we found were just introduced by the incorrect use of result_of. They were not related to N3276. IIRC, Pointer Container, Fusion and Spirit were fixed, but Phoenix is still in the fixing process.
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?
It's pretty easy for me to report the results of testing with decltype-based result_of, when the test runs successfully. But, when the test fails, it is not a trivial task for me to check whether the failure is actually caused by decltype-based result_of :/ (Of course, if someone requests testing with decltype-based result_of for a specific library, I'll try to test it :-) ) I think modifying Jamfile to add the test with decltype-based result_of is a reasonable approach to the regression tests. Regards, Michel
On 4/13/2012 7:23 AM, Michel Morin wrote:
Daniel Walker wrote:
It would be interesting to see how many Boost libraries actually require N3256.
Nathan Ridge and I made some efforts to test compatibility with decltype-based result_of. All the incompatibilities we found were just introduced by the incorrect use of result_of. They were not related to N3276.
IIRC, Pointer Container, Fusion and Spirit were fixed, but Phoenix is still in the fixing process.
Do you know if those fixes have made it to the release branch yet?
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?
It's pretty easy for me to report the results of testing with decltype-based result_of, when the test runs successfully. But, when the test fails, it is not a trivial task for me to check whether the failure is actually caused by decltype-based result_of :/ (Of course, if someone requests testing with decltype-based result_of for a specific library, I'll try to test it :-) )
I think modifying Jamfile to add the test with decltype-based result_of is a reasonable approach to the regression tests.
One way to check this on a one-time basis would be to run the tests once with tr1 result_of, and again with decltype-based result_of, and to check for new failures. We can make such a test an ongoing thing by taking one test runner and having it run in both configs. If that's the only difference between the test runs, the problem is easy to identify. Only one test runner would have to do this. I'm not sure if the test infrastructure has a way of globally adding a <define>BOOST_RESULT_OF_USE_TR1 to all targets. Does it? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
IIRC, Pointer Container, Fusion and Spirit were fixed, but Phoenix is still in the fixing process.
Do you know if those fixes have made it to the release branch yet?
Yes, they've been merged already.
I think modifying Jamfile to add the test with decltype-based result_of is a reasonable approach to the regression tests. [...] I'm not sure if the test infrastructure has a way of globally adding a <define>BOOST_RESULT_OF_USE_TR1 to all targets. Does it?
Passing a command line argument --bjam-options="define=BOOST_RESULT_OF_USE_TR1" to the test runner script (tools/regression/src/run.py) does the job? Regards, Michel
(Thomas, can you answer the question below about Phoenix?) On 4/20/2012 5:38 AM, Michel Morin wrote:
Eric Niebler wrote:
IIRC, Pointer Container, Fusion and Spirit were fixed, but Phoenix is still in the fixing process.
Do you know if those fixes have made it to the release branch yet?
Yes, they've been merged already.
Excellent, thanks. Thomas, what's the status of Phoenix re: the decltype result_of fixes Michel alludes to?
I think modifying Jamfile to add the test with decltype-based result_of is a reasonable approach to the regression tests. [...] I'm not sure if the test infrastructure has a way of globally adding a <define>BOOST_RESULT_OF_USE_TR1 to all targets. Does it?
Passing a command line argument --bjam-options="define=BOOST_RESULT_OF_USE_TR1" to the test runner script (tools/regression/src/run.py) does the job?
Sorry, is that a question or a statement of fact? If you're the clang test runner, would this be something you'd be willing to do? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
I'm not sure if the test infrastructure has a way of globally adding a <define>BOOST_RESULT_OF_USE_TR1 to all targets. Does it?
Passing a command line argument --bjam-options="define=BOOST_RESULT_OF_USE_TR1" to the test runner script (tools/regression/src/run.py) does the job?
Sorry, is that a question or a statement of fact? If you're the clang test runner, would this be something you'd be willing to do?
It was a question, but I just tried it and it works correctly. Regards, Michel
Michel Morin wrote:
Sorry, is that a question or a statement of fact? If you're the clang test runner, would this be something you'd be willing to do?
It was a question, but I just tried it and it works correctly.
I uploaded the regression test results on clang trunk in a C++11 mode (with libc++). This compiler supports N3276 decltype. * The test runner name is "clang-cxx11-r155296". I'll upload the regression test results in a few hours with BOOST_RESULT_OF_USE_TR1 on the same compiler as above. * The test runner name will be "clang-cxx11-r155296 (with BOOST_RESULT_OF_USE_TR1)". Here is a link to the regression test summary page http://www.boost.org/development/tests/trunk/developer/summary.html The test runner "clang-cxx11-r155296" is in Darwin platform. Regards, Michel
On 4/21/2012 11:12 PM, Michel Morin wrote:
Michel Morin wrote:
Sorry, is that a question or a statement of fact? If you're the clang test runner, would this be something you'd be willing to do?
It was a question, but I just tried it and it works correctly.
I uploaded the regression test results on clang trunk in a C++11 mode (with libc++). This compiler supports N3276 decltype. * The test runner name is "clang-cxx11-r155296".
I'll upload the regression test results in a few hours with BOOST_RESULT_OF_USE_TR1 on the same compiler as above. * The test runner name will be "clang-cxx11-r155296 (with BOOST_RESULT_OF_USE_TR1)".
Here is a link to the regression test summary page http://www.boost.org/development/tests/trunk/developer/summary.html The test runner "clang-cxx11-r155296" is in Darwin platform.
Awesome! Thanks, Michel. I just committed your suggested fix to Proto. That should help matters some. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
On 4/21/2012 11:12 PM, Michel Morin wrote:
I'll upload the regression test results in a few hours with BOOST_RESULT_OF_USE_TR1 on the same compiler as above. * The test runner name will be "clang-cxx11-r155296 (with BOOST_RESULT_OF_USE_TR1)".
Done.
Awesome! Thanks, Michel. I just committed your suggested fix to Proto. That should help matters some.
Line 707 of boost/proto/matches.hpp also needs the same fix. This fixes the test failure of xpressive. Regards, Michel
On 4/22/2012 3:13 AM, Michel Morin wrote:
Eric Niebler wrote:
On 4/21/2012 11:12 PM, Michel Morin wrote:
I'll upload the regression test results in a few hours with BOOST_RESULT_OF_USE_TR1 on the same compiler as above. * The test runner name will be "clang-cxx11-r155296 (with BOOST_RESULT_OF_USE_TR1)".
Done.
Thx!
Awesome! Thanks, Michel. I just committed your suggested fix to Proto. That should help matters some.
Line 707 of boost/proto/matches.hpp also needs the same fix. This fixes the test failure of xpressive.
Done. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
I just committed your suggested fix to Proto. That should help matters some.
I updated the regression test results. This time, in the Phoenix test results, http://www.boost.org/development/tests/trunk/developer/phoenix.html we can clearly see the differences between decltype-based result_of and TR1-style result_of. The corresponding trac ticket of Phoenix is here: https://svn.boost.org/trac/boost/ticket/5687 Regards, Michel
Michel Morin wrote:
I updated the regression test results. This time, in the Phoenix test results, http://www.boost.org/development/tests/trunk/developer/phoenix.html we can clearly see the differences between decltype-based result_of and TR1-style result_of.
Also, in the Functional/Forward test results, http://www.boost.org/development/tests/trunk/developer/functional-forward.ht... we can see test failures with decltype-based result_of. Regards, Michel
On 4/24/2012 3:05 PM, Michel Morin wrote:
Michel Morin wrote:
I updated the regression test results. This time, in the Phoenix test results, http://www.boost.org/development/tests/trunk/developer/phoenix.html we can clearly see the differences between decltype-based result_of and TR1-style result_of.
Also, in the Functional/Forward test results, http://www.boost.org/development/tests/trunk/developer/functional-forward.ht... we can see test failures with decltype-based result_of.
Thanks, that's now https://svn.boost.org/trac/boost/ticket/6828. I spent some time combing through the results, but found that a time-consuming way to find these sorts of bugs. I have to look at every test result for every library, making sure I'm comparing the right rows. Is there an easier way? I'm not complaining, though. It's worth it, and I greatly appreciate having these test results. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
I spent some time combing through the results, but found that a time-consuming way to find these sorts of bugs. I have to look at every test result for every library, making sure I'm comparing the right rows. Is there an easier way?
I'm not complaining, though. It's worth it, and I greatly appreciate having these test results.
I searched the test logs (without BOOST_RESULT_OF_USE_TR1) that contain `compile result="fail"` and `result_of` (plus some filters) using Ruby. Here is a list of matched results (20 items): libs/functional/forward/test/forward_adapter.test libs/functional/forward/test/lightweight_forward_adapter.test libs/fusion/test/invoke.test libs/phoenix/test/bind_not_test.test libs/phoenix/test/bind_rv_sp_test.test libs/phoenix/test/bind_stateful_test.test libs/phoenix/test/bind_test.test libs/phoenix/test/bug3289.test libs/phoenix/test/dynamic_tests.test libs/phoenix/test/exceptions.test libs/phoenix/test/if_tests.test libs/phoenix/test/lambda_tests.test libs/phoenix/test/loops_tests.test libs/phoenix/test/member.test libs/phoenix/test/new_delete_tests.test libs/phoenix/test/switch_tests.test libs/spirit/repository/test/qi_repo_advance.test libs/spirit/repository/test/qi_repo_keywords.test libs/spirit/test/lex_regression_file_iterator3-p3.test libs/utility/test/result_of_test.test Please enjoy it :-) Regards, Michel
Hi Daniel, Daniel Walker wrote:
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?
The former; there are some complaints that boost::result_of cannot deal with C++11 lambdas (without BOOST_RESULT_OF_USE_DECLTYPE). As a response to the discussions in #6728 https://svn.boost.org/trac/boost/ticket/6728 I made this post. But personally, I think using `tr1_functor` and `make_tr1_functor` (which wraps non-tr1 functors into tr1 functors using decltype) is a better idea than the approach with `cxx11_result_of`. The code for`tr1_functor` and `make_tr1_functor` is attached at http://lists.boost.org/boost-users/2012/01/72879.php Regards, Michel
On Mar 27, 2012, at 9:13 PM, Michel Morin wrote:
Hi Daniel,
Daniel Walker wrote:
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?
The former; there are some complaints that boost::result_of cannot deal with C++11 lambdas (without BOOST_RESULT_OF_USE_DECLTYPE). As a response to the discussions in #6728 https://svn.boost.org/trac/boost/ticket/6728 I made this post.
OK, yeah, life will be much better when result_of uses decltype by default.
But personally, I think using `tr1_functor` and `make_tr1_functor` (which wraps non-tr1 functors into tr1 functors using decltype) is a better idea than the approach with `cxx11_result_of`. The code for`tr1_functor` and `make_tr1_functor` is attached at http://lists.boost.org/boost-users/2012/01/72879.php
That's a good idea. I like that. - Daniel
participants (7)
-
Daniel Walker -
Eric Niebler -
Michel Morin -
Nathan Ridge -
paul Fultz -
Philipp Moeller -
Stephan T. Lavavej