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
> > 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
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.
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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk