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

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-25 17:47:53

On 25 Aug 2015 at 12:30, Robert Ramey 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've been watching Fiber closely since we reviewed it. As far as I 
know, the public API has barely changed. The documentation has 
improved in all the areas the review recommended. Just because the 
internal implementation is radically different does not mean it has 
morphed into something significantly different.

For example, Oliver is considering making boost::fiber::future<> 
based on my Monad/Outcome Concurrency TS custom future framework as 
why bother duplicating the work. If he did, even then the public API 
reviewed and accepted into Boost remains exactly that which was 
reviewed and accepted. You don't really need to know or think about 
Monad/Outcome for boost::fiber::future<> to work as a C++ 11 type 
future.

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

I think he saw a chance to make his internal implementation code 
vastly simpler and easier to maintain yes. Same as me. We're going to 
be supporting this thing for a decade or so, it makes sense to invest 
in saving ourselves work.

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

I agree.

But I draw the line between API and design and then the internal 
implementation. If it's just the latter which has changed and the API 
and design is identical, I think a mini-review is enough.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/