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-09 18:39:49

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.

> 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.

That's reasonable, in the absence of time constraints.

> 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.

I like this idea, and it sounds like a good long-term solution. I don't
think we have time to try this change out in the 1.43 time-frame,
though. 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?)

I like the idea of making a separate TR1-style result_of available to
the libraries that need it. Whether it should be part of Boost.TR1
(std::tr1::result_of) or whether it should be part of Boost.Result_of
(boost::tr1_result_of or some such) is an open issue, and I don't have
strong feelings.

My only strong feeling is that we need to decide soon what change to
make for 1.43, and it should be a small change. To me, that argues for
simply backing out the decltype implementation for 1.43.

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