Boost logo

Boost :

Subject: Re: [boost] Futures Review Starts Today - January 5, 2009
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-01-06 18:40:43

----- Original Message -----
From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
To: <boost_at_[hidden]>
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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at