Re: Futures Review Starts Today - January 5, 2009

----- Original Message ----- 
From: "Phil Endecott" <spam_from_boost_dev <at> chezphil.org>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 06, 2009 11:44 PM
Subject: Re: [boost] Futures Review Starts Today - January 5, 2009

> One of the things that Boost tries to be is a proving-ground for things 
> that are heading towards C++ standardisation.  In this case it seems to 
> have gone topsy-turvy: the C++ standards committee have approved an 
> implementation of futures and now Boost is reviewing two libraries 
> neither of which is an exact implementation of the standard proposal.  
> This doesn't seem right to me.  So:
> 
> - The idea of futures looks useful and I think Boost should have it.

I agree completly.

> - It would not be sensible to have anything other than something 
> conforming to the proposed standard, except for any hacks necessary for 
> pre-0x compatibility and perhaps for non-conflicting extra features.

I agree again.

> - I believe that both of the proposals were ready for review some time 
> ago.  I'm unsure of the exact chronology but I have the impression that 
> if they had been reviewed by Boost more promptly then perhaps that 
> review could have been available to the standards committee.

I think this was the intention of Anthony.

> - I understand that the slowness of the review queue is a result of too 
> few review managers for too many proposed libraries.  Assuming that the 
> pool of review managers can't be pressed to give up more of their time, 
> maybe the pool could be widened by relaxing the required 
> qualifications: although reviews often require that the review manager 
> does a lot of collating of opinions, I'm not aware of many cases where 
> the essential accept/reject decision has been very difficult to make or 
> is different from what a vote-count of reviewers would have said 
> (though maybe I'm wrong).  

Where can we found the required qualifications of a review manager?

> Alternatively maybe the other end of the 
> problem should be fixed by attempting to limit the scope of 
> contributions to focus more on "core" features that might one day end 
> up in std::c++.

Which Boost libraries can not one day end up in std::c++?
In any case I don't thik this limitation will be useful.

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost