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/