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

Subject: Re: [boost] [result_of, tr1] decltype and incomplete types
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-04-11 12:37:38

On Sat, Apr 10, 2010 at 7:50 PM, Eric Niebler <eric_at_[hidden]> 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