Re: [boost] [result_of, tr1] decltype and incomplete types

Subject: Re: [boost] [result_of, tr1] decltype and incomplete types
From: Eric Niebler (eric_at_[hidden])
Date: 2010-04-10 19:50:31

On 4/9/2010 5:31 PM, Daniel Walker wrote:
> 
> The decltype result_of isn't on the 1.43 release branch. I believe
> Daniel James reverted the changes last night. 

Yes. He also reverted a bunch of other fixes, which seems unfortunate to
me. I can live with that, though.

> So, as of right now,
> 1.43 won't ship with the decltype result_of, which is acceptable to
> me, but I still think we should leave the code on trunk for anyone who
> uses trunk.

I think on trunk we should start moving toward whatever solution we feel
will be appropriate for 1.44.

> 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.

> 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.

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.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com