Re: Revitalization

From: Proton (matt_at_[hidden])
Date: 2022-12-06 03:38:29

> On Dec 5, 2022, at 6:58 PM, Vinnie Falco <vinnie.falco_at_[hidden]> wrote:
>
> On Mon, Dec 5, 2022 at 6:36 PM Proton <matt_at_[hidden]> wrote:
>> I am willing to assist other maintainers in offering a standalone module of their libraries.
>
> Sloooooooooow down there cowboy :)
>
> I'm not suggesting to start turning out a series of Boost libraries
> converted to standalone. That's not going to be practical, because
> there are Boost facilities that are too darn good to do without:
>
>    Boost.Align - everything
>    Boost.Assert - BOOST_ASSERT, source_location, current_function
>    Boost.Config - everything
>    Boost.Container - memory_resource for C++11
>    Boost.Core - string_view, allocator_traits
>    Boost.Describe - practical reflection
>    Boost.Mp11 - everything
>    Boost.System - error_code, result
>    Boost.ThrowException - throw_exception (attached stacks)
>    Boost.Variant2 - A never valueless variant (how it should have been)
>
> These libraries are important for me and I find myself using them in
> every single project I author. The features fall into several
> categories:
>
> * Utilities to help code work on all toolchains
> * C++11 implementations of C++17 or later features (string_view, variant2)
> * Better versions of things in C++ (throw_exception, error_code)
> * Features that would be a pessimization to have to reimplement (Mp11,
> Describe, et. al.)
>
> The original release of Boost.JSON had a "standalone" mode but I
> quickly ran into the problem where denying myself access to all of the
> useful libraries described above became unworkable.
>
> We might consider offering smaller a-la carte bundles of Boost
> libraries. For example, bundle the libraries above into a "Boost
> Essentials." Of course this might be a dumb idea and I will not be
> offended if anyone says so. Making Boost.JSON, Boost.URL,
> Boost.HTTP.Proto "mostly standalone" (i.e. depend only on a "Boost
> Essentials" type library) is much more realistic than having to make
> it totally standalone and reimplement everything over and over.
>
> There is also another problem which is that as I write higher level
> libraries, I depend on the lower level libraries. For example:
>
> Beast depends on Asio
> HTTP.Proto depends on URL
> HTTP.IO depends on HTTP.Proto and Asio
>
> A hypothetical "Boost.HTTP.Requests" library would depend on Asio,
> HTTP.Proto, HTTP.IO, and Boost.JSON.
>
> And so on. It is not sustainable to try to make every single library
> standalone. This subverts the benefits of separation of concerns and
> physical separation of libraries. Instead we should focus on how we
> can make it more palatable for users to add our libraries to their
> project, if not the singular monolithic Boost installation, then
> perhaps the smaller library aggregates I alluded to above.
>
> Thanks

For higher level libraries bundling is certainly more practical. I think there are other libraries like Math that don’t require anything Boost for proper functionality. Most of Math’s Boost dependencies were features replaced in C++11 (e.g. array, atomic, type_traits, etc.). Either way, we are experiencing success moving away from the monolithic dependency, and I expect others would have a similar reception.

Matt