Re: [boost] decltype and incomplete types

Subject: Re: [boost] decltype and incomplete types
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-04-09 16:48:16

On Fri, Apr 9, 2010 at 3:11 PM, Eric Niebler <eric_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 4/8/2010 4:28 PM, Daniel James wrote:
>> On 8 April 2010 23:51, Eric Niebler <eric_at_[hidden]> wrote:
>>>
>>> Thanks. The change should also be applied to truck, otherwise, those of us
>>> who use truck testing to know when to merge things to release won't be
>>> getting an accurate picture of things.
>>
>> That's probably true, although utility hasn't been the same on trunk
>> and release for a long time, I merged the result_of changes mainly to
>> fix that. I'll leave it Daniel Walker to decide what he wants to go
>> from here.
>
> Daniel? 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. Actually, I think it would be nice in the future if
boost::result_of kept in close synch with the draft as it's finalized.

In that spirit, here's another possible solution for the current
release that may address your concerns Eric, without inhibiting other
users. Boost packages/distributes a TR1 implementation. Why not copy
the TR1 result_of implementation to Boost.TR1? That way Proto and
anyone else who designed for TR1 could rely on Boost.TR1 result_of to
remain as it is. Meanwhile, boost::result_of could offer c++0x
compliance, and eventually, other new features. If this sounds
reasonable I can put together a patch right away.

Daniel Walker