Re: What is this "Beman Project Development" exactly

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-05-09 11:06:22

On 5/9/24 13:52, Boris Kolpackov via Boost wrote:
> Robert Ramey via Boost <boost_at_[hidden]> 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.