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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-11-26 14:13:40

On 11/26/23 06:27, Vinnie Falco wrote:
> 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.

This has nothing to do with being strictly limited to the standard
definition of the component. You can use `boost::optional` since C++03
whether or not it offers extensions compared to `std::optional`.

>> 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."

I am. Specifically, I'm using Boost.Atomic, Boost.Regex and some bits of
Boost.Thread over the standard components because they either better fit
my needs or offer better performance. I also find myself using
Boost.Intrusive and `boost::intrusive_ptr` much more often than the
standard containers and `std::shared_ptr`.

> 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.

Sorry, I don't get this logic. You used a library for many years, with
all its features. Now a standard component appears that lacks some of
the features you use. Yet you still decide to switch to it despite the
inconveniences and lacking functionality. And somehow the library that
served you well is to blame for your trouble?

The way I see it, you (the one who decided to switch) is the one to
blame in this situation. I don't mean this in an accusatory way, and
there may be valid reasons to switch. But still it was your decision to
switch despite the consequences, and thus you are the one responsible.

> 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.

You are, of course, free to do so, including in case of Boost.Scope. But
the way I see it, this is hindering innovation and would play towards
Boost stagnation.

>> 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.

I'd like to think everyone is free to make their own choice based on
their own criteria and merits of each of the options. Availability of
the standard library is an important advantage, but it is not ultimate.
Personally, I find the standard library severely lacking, meaning I
cannot reasonably write a serious project relying solely on the standard
library and nothing else. I'd have to write a lot of code that I know
exists and tested in other libraries like Boost, and I'd have to be mad
not to try and reuse it. So you could say Boost is my natural extension
of the standard library, something that I always have by my hand, just
as easily reachable as the standard library.

BTW, on the topic of innovation and stagnation, my other complaint about
the standard library (or rather its implementations, every one of them)
is that once a feature is implemented, it gets frozen because of ABI
stability. Stable ABI is important, but because of it bugs like this[1]
never get fixed.

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978