On Tue, Sep 10, 2024 at 2:34 PM David Sankel via Boost
...Boost is not part of the incubation process for most libraries going into the standard. As to why this is the case, I don't think anyone knows for sure.
I have a theory. There are two approaches to building standard library components: Approach A: 1. Think of a useful library and write it 2. Maintain and improve the library 3. Propose it for the standard Approach B: 1. Think of something for the standard 2. Write a paper and/or reference implementation 3. Propose it for the standard Both of these approaches have the same end result: a new library added to the standard. And yet there are big differences between them: What kind of person goes for each approach? A: Someone who loves having users B: Someone who loves getting something into the standard Who does the author have in mind when writing the library? A: The general C++ community B: The people voting in WG21 What does the competition look like? A: Anyone can write a competing library on equal footing B: Standardized library components have a built-in competitive advantage What is the influence of politics? A: Politics can't make people use your library if it sucks B: In the WG21 bureaucracy, playing politics is essential (cue Gor's quote that "90% of the work of landing coroutines was non-technical") There are statements made which refer to "Boost's original purpose" and such, but this entirely misses the point. Boost used "Approach A" to get libraries into the standard. Authors wrote useful things such as boost::shared_ptr. They were adopted by the community, and then they made their way into the standard. The committee moved slowly then, so libraries had time to bake. The problem with WG21 is not that people aren't writing the libraries first before submitting the paper, it is that they are writing the library with standardization in mind first and foremost, rather than satisfying the larger community of C++ users. It helps to look at some examples: fmtlib::fmt (now std::format) This library came out in 2015. It was immediately useful and found its way into many projects. It had to compete with std and other libraries, and it won. Many users, many improvements. The paper was not presented until two years later, and it went through a couple of years of revisions. This used Approach A. std::format is a great standard library facility, and became so because it was forged in the fires of competition. Asio This library joined Boost in 2005. It underwent many revisions and was adopted in quite a few code bases. No other library offers the portability and adherence to C++ idioms that Asio offers. It gained many users, and many other libraries were written on top of it (second order effects). This used Approach A. The Networking TS was proposed, but certain factions in WG21 had Other Ideas and it was scuttled. The consequence is that C++ still cannot connect to the Internet. And there is no relief in sight. std::ranges This is basically version 3 of Boost.Range. The author decided it would be better to write it as direct-to-standard as that would be easier than going through Boost. And the Standard C++ Foundation paid the author to do the work, with a directive to emphasize the use of concepts to drive adoption of the newer C++ language versions (I think). This used Approach B. std::ranges was effectively impossible to implement without the new language features, so users did not really have the opportunity to try it. That is, std::ranges was never exposed to the competitive marketplace of users. Compare this with Boost.Range, which never went into the standard and was developed with Approach A. It is still used today, because it is useful (not overly complex). Companies are now realizing the shortcomings of std::ranges and investigating alternatives. Example: Rappel: Compose Algorithms, Not Iterators Google's Alternative to Ranges https://www.youtube.com/watch?v=itnyR9j8y6E std::execution This started out as a series of papers which gained the informal term "Senders/Receivers." Its alternative model of asynchrony competed with the Networking TS, so the Asio-based paper became politically disfavored and abandoned in favor of the new thing which is now called std::execution. This is an example of Approach B. std::execution never gained any meaningful users, and was never exposed to the competitive marketplace of users. Most users who do not follow WG21 comment on the complexity and foreign look of example code related to std::execution. Like std::ranges, companies are already anticipating that the std story for asynchrony is going to be dysfunctional on arrival and investigating alternatives. Example: https://www.youtube.com/watch?v=nQpXOx0D7I8 I believe that making standardization the primary goal is a mistake. The goal must always be to satisfy users by delivering something useful. The standardization follows, and does not lead. This is why Boost is now more important than ever: WG21 is incapable of competing in the library marketplace. Thanks