On 5/9/24 13:52, Boris Kolpackov via Boost wrote:
Robert Ramey via Boost
writes: Here is the "mission statement" from the Boost Foundation website:
"The Boost Foundation’s broad C++ mission is: (a) development of high quality, expert reviewed, legally unencumbered, open-source libraries, (b) inspiring standard enhancements, and (c) advancing and disseminating software development best practices. It does this by fostering community engagement, nurturing leaders, providing necessary financial/legal support, and making directional decisions in the event of Boost community deadlock."
[...]
Here is the "mission statement" from the Beman Project:
"The Beman Project’s mission is to support the efficient design and adoption of the highest quality C++ Standard libraries through implementation experience, user feedback, and technical expertise. Founded at C++Now in 2024 the project strives to aggregate libraries proposed for ISO standardization making a simple usage experience for the C++ Community to try out new libraries. For library authors we assist by helping to make best modern development practices easy. Including CI, coverage, and packaging."
Seems to me that they are essentially the same with different wording [...]
Seems very different to me: the Beman Project appears to be focused on libraries aiming at being included into the C++ Standard Library. This means they don't have to worry about any of the Boost baggage:
1. They can track the latest standard (since by definition such libraries will only be usable with later standards). Maybe they can even go straight to modules.
2. Not worry about build systems and package managers (they can live in the blissful world of C++ that has a standard package manager, it just has one giant package that gets a new version every three years).
I don't think #2 is true, and I doubt #1 is entirely true either. A library proposed for inclusion into the standard has to work and solve the intended problem efficiently. This means testing and field experience are prerequisite, and for that the library has to be usable with current compilers, even if modern. And yes, that includes a build system and packaging, if required by the library. That is unless the LWG is willing to accept unverified and half-baked libraries into the standard library, which I strongly hope is not the case.