Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-04-29 23:05:43


On 4/27/23 18:16, Peter Dimov via Boost wrote:
> Newer C++ standards (20) have been adding useful things to the
> standard library (<bit>, <latch>, etc) and most of us would like to
> use them, both in Boost and outside of it, while still supporting
> C++11, or 14, or 17.
>
> Many of these components are straightforward to implement
> using the C++11 standard library, consist of not much than one
> relatively small header, don't need many Boost dependencies
> beyond the required ones (Assert, ThrowException, Config), and
> since their interface is already fixed by the standard, don't need
> a design review.
>
> It would be nice if we had a dedicated place in Boost where to
> put these, to avoid the need for everyone reimplementing a
> private copy.
>
> At the moment, some of these have gone into Core, for lack of
> anywhere else, and we now have a <latch> contribution (which I
> encouraged):
>
> https://github.com/boostorg/core/pull/144
>
> However, Core is not quite the right place for these components.
>
> So my suggestion is to create a separate library/repo, Boost.Compat
> (boostorg/compat, namespace boost::compat) for them.
>
> Thoughts? (Be sure to read the discussion in the PR as well.)

My main concern in the aforementioned PR was increased code duplication,
and it isn't fixed by having Boost.Compat. I really don't like us having
multiple copies of the same components for the sole purpose of reducing
dependencies (in the case of latch - reducing tests dependencies, not
even library dependencies). If we don't want to use the libraries we
write and accept during the review then there must be something wrong
with Boost. This isn't good for Boost (more maintenance required, less
overall quality because some parts are left unmaintained) and this isn't
good for users (more confusion, more compatibility issues).

Secondly, I'm not sure I like the idea of another kitchen sink kind of
library a-la Boost.Core and Boost.Utility, as such libraries tend to
become bloated over time. Such libraries are also inconvenient for
users' consumption, as it is more difficult to find a component in one
of such libraries compared to in one of the specialized ones. I would
prefer us to keep evolving our existing libraries, where appropriate,
and accept new ones, where their functionality is not covered by the
existing ones.

And lastly. I realize that the proposed Boost.Compat is supposed to
contain direct equivalents of the standard components. But what if we
want to improve on that? Would this be not allowed simply because this
would deviate from the standard? If allowed, would this still not
require a review? I think, the "no review required" policy might be a
bit too permissive.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk