On 4/11/2010 12:29 PM, Eric Niebler wrote:
On 4/11/2010 9:37 AM, Daniel Walker wrote:
On Sat, Apr 10, 2010 at 7:50 PM, Eric Niebler <eric@boostpro.com> wrote:
If Boost.TR1 advertises itself as an implementation of TR1, then it should have an implementation of result_of that doesn't rely on decltype. (Waiting for John to jump in here.) That way, libraries like Proto that need the tr1 behavior (until decltype is fixed) can use std::tr1::result_of from boost/tr1/functional.hpp and forget about it. This should be possible in the 1.44 time frame and is a good long-term solution.
Agreed.
Note that to make this happen, you'll need to coordinate with John. The way Boost.TR1 works is like this:
- If the platform implements <tr1/foo_header>, include it. Otherwise, - Include <boost/foo_header.hpp> and bring boost::foo into the std::tr1 namespace with a using declaration.
If boost::result_of sometimes uses decltype, the above won't work because then std::tr1::result_of will sometimes use decltype. It seems to me that <boost/utility/result_of.hpp> should expose a boost::tr1_result_of that can be used by <boost/tr1/result_of.hpp> to get the TR1 behavior regardless of whether decltype exists or not.
I opened a ticket for this (milestone 1.44) and attached a patch: https://svn.boost.org/trac/boost/ticket/4084. I noticed that the decltype change to result_of was causing regression failures in TR1 by making the implementation of TR1's result_of non-compliant. The patch fixes the issue and adds a boost::tr1_result_of. The regression test failures may be more evidence that the change to result_of was a bad idea (as well-intentioned as it may have seemed). This patch may not be the last word on the issue. I'm still uncomfortable with the change to boost::result_of, which is likely to break users' code. Perhaps we could place the new decltype implementation on a compile-time switch (BOOST_RESULT_OF_USE_DECLTYPE?) so that users can opt in. That wouldn't eliminate the need for boost::tr1_result_of or something like it, though. Cheers, -- Eric Niebler BoostPro Computing http://www.boostpro.com