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-11 17:47:30

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_at_[hidden]> 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