Re: [boost] decltype and incomplete types

Subject: Re: [boost] decltype and incomplete types
From: Eric Niebler (eric_at_[hidden])
Date: 2010-04-09 15:35:20

On 4/8/2010 4:25 PM, Daniel Walker wrote:
> On Thu, Apr 8, 2010 at 6:51 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> On 4/8/2010 3:07 PM, Daniel James wrote:
>>> This reverts the fixes for:
>>>
>>> https://svn.boost.org/trac/boost/ticket/862
>>
>> Support for boost.lambda.
>>
>> This bug is invalid to begin with. Lambda should be changed to support the
>> TR1 result_of protocol (which is standard), not the other way around.
> 
> No, the result_of in this patch can detect the type of any callable
> object, including those from boost.lambda, in contexts where the type
> of the call expression is complete. Now, lambda users who would like
> to query the type of lambda function objects should use their
> compiler's std::result_of, if it implements any draft of the standard
> from the past 2 years, or simply roll their own.

Hi Daniel,

IIUC the fix here for Boost.Lambda was to implement the c++0x result_of
on supporting compilers. That's fine -- as long as you accept that a
decltype-based result_of is a safe substitute for the TR1 result_of,
which I don't.

My point above was that this bug should have been closed "Invalid"
because it's not a result_of problem. The problem is that Lambda doesn't
support the TR1 result_of protocol. This isn't news. The standard
response is to use Phoenix. I don't particularly like that answer
because ...

(a) Phoenix isn't a top-level boost library and is likely to change once
we get Phoenix ported to Proto, and

(b) Lambda has a big installed user-base who won't benefit from
improvements to Phoenix.

But all this is a side issue. The real issue is to back out the decltype
change (and ONLY the decltype change) to result_of on trunk, and merge
the change to release as soon as we get the green light from the
regression tests.

Let me know if you need a patch for this.

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