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-09 20:31:23

On Fri, Apr 9, 2010 at 6:39 PM, Eric Niebler <eric_at_[hidden]> wrote:
> CC'ing John Maddock because this now involves Boost.TR1.
>
> On 4/9/2010 1:48 PM, Daniel Walker wrote:
>> On Fri, Apr 9, 2010 at 3:11 PM, Eric Niebler <eric_at_[hidden]> wrote:
>>>
>>> Ideally, we should get the other fixes back, but just comment
>>> out the check for BOOST_NO_DECLTYPE and always select the TR1
>>> implementation.
>>
>> If it's no problem to merge the other changes to release, that sounds
>> good. But I'd like to leave trunk as is for the time being. We waited
>> until the standards committee voted to accept decltype and the new
>> result_of before adding the implementation to trunk. I think we should
>> wait for the committee to respond to our experience before taking a
>> step backwards.
>
> IIUC, we haven't yet shipped a version of result_of that uses decltype,
> so this wouldn't be a step backwards. This would merely be deferring the
> step forward until we can do so more confidently.

The decltype result_of isn't on the 1.43 release branch. I believe
Daniel James reverted the changes last night. 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.

> <snip>
> I looked at the TR1 stuff, and it looks scarily complicated. It
> conditionally uses the platform-supplied headers if they're available.
> The question then becomes whether those headers (over which we have no
> control) will switch to decltype once it's available. (John?)

Good point and fyi, gcc 5.0 does use decltype in it's 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.

Daniel Walker