On Sat, Apr 10, 2010 at 7:50 PM, Eric Niebler <eric@boostpro.com> wrote:
On 4/9/2010 5:31 PM, Daniel Walker wrote:
fyi, gcc 5.0 does use decltype in it's headers.
You mean gcc-4.5? I see a tr1/functional header there that has an implementation of result_of that doesn't use decltype.
Sorry, yeah, 4.5. That's good news that they have a correct tr1/functional header. I didn't notice that at first. However, the regular gcc functional header does use decltype result_of. The two headers use two different namespaces, std::result_of and std::tr1::result_of, which is good. That will prevent folks from inadvertently using one and not the other, and Boost.TR1 will still be able to get TR1 result_of from the gcc headers.
So, if we want Boost.TR1 to be TR1 on gcc 5.0 we may need to make a change or two. 5.0 was released 2 weeks ago.
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.
In that world, boost::result_of could be free to use decltype or not as appropriate. But to be honest, I don't particularly like the fact that boost::result_of behaves differently depending on whether decltype is available or not -- it hurts code portability -- but utility/result_of is your baby now, and it's your call.
Well, function objects written for c++0x will only work with TR1 result_of if they use the old, intrusive protocol to specify the (complete) type of the call expression. However, the TR1 protocol is not necessary in c++0x, which is a good thing. But your point is well taken, and I think portability should be an important consideration regarding any future changes. Daniel Walker