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@boostpro.com> 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