Re: Revitalization

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2022-12-06 02:58:04

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