On 9 May 2014 at 8:23, Sebastian Theophil wrote:
The dev list is down about 30% 2011 onwards as against before 2011.
Monthly commits to Boost are about 500 per month since 2011 as compared to about 1000 per month before 2011.
don't forget that the marginal usefulness of every new contribution might be shrinking.
I think that is exactly the case. There are two Boost libraries, and the compatibility part is suffocating the push-the-boundaries part.
Many Boost libraries were essential for C++03 users but become less useful once you've migrated to C++11. They were testing grounds for new standard features. The better the standard library, and the better the programming language itself, the less need there will be for an extensive library as boost.
Hence the need for a suite of libraries which are testing grounds for new standard features in C++ 14, letting you push the language as far as it can go.
Seen through that lens, a dying boost library might be a good sign. Though I don't actually believe the dying part yet. There are still many useful libraries in boost that haven't made it into the standard. There are even more libraries I'd like to be included in boost, thus becoming default choices, even if they can never make it into the standard.
If a general purpose (not single purpose) Boost library didn't overwhelmingly persuade of the need for inclusion into the standard for 11/14, I doubt it would in its current form for 17 and beyond. For example I think we'd all like something like ASIO in the STL, but current ASIO is very big and monolithic, and would I think look a lot more modular if rewritten to use Concepts Lite. ASIO also doesn't need Boost, and therefore could exclusively use the C++ 14 STL instead (BTW, proposed AFIO is exactly the same, once expected<T> is ready I hope to drop the requirement of Boost.Thread). It would also help if ASIO were adapted into the latest improvements to async e.g. executors, expected and so on such that it was also one of many ways to do async. I'm sure that's coming eventually anyway. Then one might see a case for it entering the STL. Right now, I think the potential improvements are too obvious, and therefore the stability insufficient for standardisation. Something needs to become boring for it to be standardised. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/