On Tue, Sep 10, 2024 at 1:50 PM Andrzej Krzemienski via Boost
I have always thought that Boost was conceived to help create high-quality libraries, with the purpose in mind that they would be good candidates for standardization. The quality would have been achieved through the thorough Boost Review process, and then through collecting user (commercial and private) experience. Boost evidently fulfilled this role. Boost libraries are still proposed for standardization: Boost.Static_vector and Boost.ASIO.
These kinds of additions are pretty rare. Compare static_vector, flat_map, and the modification of optional to have the T& sepcialization to the number of library features added in the same time period that did *not* come from Boost. Also, all of those things are "old" in some sense. None of them was added in the last 10 years.
I would expect that the Boost Foundation Board members present at WG21 (the ISO/IEC C++ Standards Committee) meetings would encourage the proposal authors to take the Boost path. Do they?
Sure. I've tried, and *hard*. Tony Van Eerd and David Sankel are also two regulars who ask, "Why isn't this a Boost library?" There are almost never any takers. It comes down to this: 1) It's another hurdle to jump. Getting something through committee review means handing off maintenance to library implementers. Going through Boost first means dealing with yet another specific process (that's a lot by itself), but also incurring a long-lived maintenance task as well. 2) Boost is not a very welcoming place. I have had at least one WG21 member show up here, at my behest, be treated "quite rudely" by his lights, and then promptly leave, never to return. I have heard many people say the same thing at conferences over the years (so, not WG21 folks necessarily). And before you debate whether this is a justified reaction, or say these people are thin-skinned weenies or whatever, know that such a debate does not ultimately matter. If people feel unwelcome or that interacting with this list is futile, they won't bother. 3) The tools suck. Boost build and our doc chain are great once you have them set up, but are impenetrable to newcomers. They are non-standard, which is unavoidable for a doc chain (there is no de facto standard), but odd and disappointing when it comes to build (the world has standardized on CMake, for better or worse). 4) The one time I managed to cajole someone into doing a Boost review, it was rejected because people didn't see the point of it. I'm still not sure why that was. It had a point, is quite useful, and is now in the standard. At the time of the review, it was clear that this was probably going into C++ with or without Boost, and people also did not care to have it in Boost for that reason. One kind of Boost library content is implementations of things that are in the standard that might not yet be in your implementation. This was a chance to influence the direction of a standard library entity, and people did not see that opportunity for influence to be worth their time. That last point is very important. #4 is not a criticism, so much as pointing out a very different orientation of Boost vs. WG21. There's nothing wrong with this. It does however indicate that a new project, focused exclusively on road-testing new libraries bound for the standard, should be created. That project is Beman.
Of course, the proposal authors may not want to do it for valid reasons. In that case, I would expect Boost Foundation Board members present at WG21 meetings to collect these reasons and report them to the Boost community, e.g., via the Boost Developers mailing list. Is this happening?
I've said these things at various times, on the list and off, but what I wrote above is the first time I've tried to summarize all the issues in one place.
I hear from my colleagues in WG21 that it is Boost leaders that proposed the Beman project because they do not think Boost works well. This is more like a rumor, so one can hardly build their position based on this, but it adds to the impression that there is a subset of the Boost Foundation Board members who do not believe Boost is capable of fulfilling the mission of incubating the libraries intended for standardization.
This is not accurate. I think the consensus among Beman participants is that Boost should do what Boost does well -- peer reviewed C++ libraries -- and Beman should do its thing -- provide a testing ground and distribution mechanism not for C++ libraries in general, but for C++ standard library entities *only*. These are very different aims.
They may be right. But in that case, I think the Boost community deserves to hear the reasons.
My impression might be wrong and unfair, therefore I would like the people to respond to this, and possibly clear things up.
Hopefully what I wrote answers your questions.
I know this is long and unstructured, so thank you for reading till the end. I hope I managed to get across why the question about the Beman Project is relevant in the context of the Boost Asset Stewardship Review.
Not at all. Thanks for bringing this up. Zach