Re: [Boost-users] [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [Boost-users] [boost] [afio] Formal review of Boost.AFIO
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-08-25 15:30:01

On 8/25/15 10:28 AM, Niall Douglas wrote:

> There is precedent for this: Boost.Fiber was provisionally approved
> here as a C++ 98 library with condition of a mini-review before
> entry. Boost.Fiber is now a C++ 14 library and sufficiently different
> from the library originally reviewed it may require a second
> mini-review if during its first mini-review it is felt still lacking.

This is a precedent - a bad one which I hope to avoid a repetition of in 
the future. A library which is accepted should be close enough to it's 
final state so that it can be finished up on the order of a couple of 
months and will result in a final version which is close to what 
reviewers actually reviewed.

We can't have a library pass a review, then have the package morph into 
something significantly different then have it accepted.  This make the 
original review a farce.

> I think this pattern of repeated mini-reviews caused by changes to
> the common implementations of the C++ standard rather than the
> libraries themselves is going to be very common next few years.

LOL - maybe, but only if we let it.

All
> these changes to AFIO are almost entirely driven by changes since
> 2012 to the various WG21 technical standards. If they hadn't changed
> and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't
> have changed.

> It's very similar for Fiber, which had to be refactored
> in the face of substantial changes in C++ 14.

I seriously doubt that a package which compiles and passes tests and 
reviews with C++03 cannot do these things when C++11 comes out.  What 
really happens is that the author sees opportunities with C++11 that he 
didn't have before then starts incorporating them after the original 
review.  I guess this would be called feature creep or implementation 
creep.  In any case, it indicates that the original acceptance was 
premature.

Ultimately it hinges on what "acceptance into Boost" means.  To me it's 
a library ready - with a few straight forward / uncontroversial changes 
which is ready to be incorporated into the boost distribution. It's not 
acceptance of an idea for a library, a prototype for a library, or that 
a developer is certified to add a library in the future.

Robert Ramey