El 23/05/2020 a las 13:24, Andrey Semashev via Boost escribió:
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.
From the article:
if you were writing a new candidate Boost library with C++11 as its 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.
Boost.Regex is admittedly a controversial point (as mentionedin the proposal) due to its superior quality to some std implementations. But there are other components whose usage I find it hard to justify, such as Boost.Array and Boost.Tuple (there may be others). Whatever the intrinsic qualities of these foundational libraries, they seem to totally be losing the PR battle against std counterparts (if that was a battle to begin with, that is): https://github.com/joaquintides/boost_epoch/blob/master/boost_vs_std.md
[...]
Next, I disagree with the idea that a library could be "not allowed to progress". Why block further improvements and extensions?
In the section quote from, "progress" means "be given the newer epoch badge". I'm not referring to preventing the author from evolving their lib, which is their unalienable right.
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.
The crucial point here is to what degree this extra functionality in Boost.X is actually used by other Boost libraries when Boost.X is a dependency. I don't have hard data (you don't provide any either) but I suspect this degree is very low. On a more philosophical note, one of the goals of Boost is: "We aim to establish 'existing practice' and provide reference implementations so that Boost libraries are suitable for eventual standardization." In this regard, Boost has been extremely successful up to C++11, moderately so ever since. But one aspect that wasn't planned or even discussed when Boost started 22 years ago is: what do we do after standardization. Epochs is one answer to that. Regardless of the merits of this proposal, I think we owe ourselves a discussion around this central topic of coexisting with an evolving standard that is expected (and helped) to take over much of the user base of components originated outside. Joaquín M López Muñoz