On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:
Hi,
Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list:
https://github.com/joaquintides/boost_epoch/blob/master/README.md
I hope the proposal can start a productive conversation. Looking forward to your feedback.
if you were writing a new candidate Boost library with C++11 as its
From the article: baseline, would you strive to use std components rather than their Boost counterparts, no matter how good the latter are? I would say you would. I would not. As a user (either in-Boost or external) I would choose the library that is technically better. Boost.Regex is actually a very good example of such, as it is considerably faster than at least some popular std::regex implementations. There are other examples where Boost equivalents are technically better in one regard or another than the standard counterparts. I do not think discouraging use of (better) Boost libraries just because there is a counterpart in the standard library is a good idea. Using the best available tool should be a welcome choice on Boost developers side. Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions? Take Boost.Atomic or Boost.FileSystem, for example. These libraries are not equivalent to the standard counterparts, and offer extensions that are useful in practice and cannot be efficiently implemented "on top" of the standard components. What would be the point of a Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are spreading our time thin as it is already. The above examples are not an exception. I think, almost every library that was adopted by the standard is not equivalent to the standard component. Some of them have continued to evolve since adoption, and results of this evolution may be adopted by the standard in the future. I see no point in creating new versions of such libraries on each iteration of such adoption.