Re: [scope] Scope review starts on November 26th

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2023-11-26 03:27:15

On Sat, Nov 25, 2023 at 6:17 PM Andrey Semashev via Boost
<boost_at_[hidden]> wrote:
> I think there's little point in introducing new libraries that are
> predetermined to be locked down to be strictly equivalent to the
> standard C++ components.

Au contraire, mon ami; A Boost library which is "merely" strictly
equivalent to its std counterpart offers one significant quantum of
value: it can be used in versions of C++ which are older than the
standard in which the std component was introduced.

> The fact that some Boost libraries that now have standard counterparts
> have certain extensions is a good thing because it offers users a choice
> and provides them the functionality they need.

This might have been a convincing argument five years ago, but
empirical evidence disproves this claim. No one is intentionally
choosing Boost's error_code, filesystem, or thread over the std
equivalent because of "the functionality they need."

The reality is that people end up using the boost equivalent
components because they are forced to. Either because an upstream
library requires it, such as Asio, or because it is already in the
existing code base. Users have clearly indicated that they vastly
prefer the std component over the Boost one regardless of whether the
boost component offers additional value.

The only time the boost component is preferred, is when the additional
functionality is so significant in the value that it brings, that it
justifies the additional friction required to integrate the component.
One example that comes to mind is Boost.Variant2.

New features added to std-flavored boost components become incredibly
annoying years later when a project wants to switch back to the std
equivalent, perhaps because they were finally able to upgrade to the
latest C++. They discover they have to perform a non-trivial
refactoring of the code base because over time these additional
features that we added end up getting relied upon and cannot be
extricated easily.

Every time I try to talk people into using Boost this issue of boost
having copies of std components comes up and not in a positive way. In
fact, I think from now on I will write a very short review which
encourages to REJECT any proposed library which clones std components
and adds or changes anything, unless the feature or modification is so
incredible that it "walks on water." I look forward to seeing whether
these vaunted Boost.Scope "additions" meet this criteria.

> The fact that the standard doesn't provide that functionality (provided that it is needed by users) is a deficiency of the standard, not the Boost library.

Users vastly prefer even the "defective" std components over the
theoretically-better boost components, simply by virtue of them being
in the standard, with all of the benefits this brings. Education,
documentation, ubiquity, and so on, for std components is orders of
magnitude more robust than the boost equivalent. This more than makes
up for any perceived deficiencies. Like it or not, vocabulary types
and algorithms which make it into std are going to have an enormous
advantage over any third party code.

Thanks