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

On 11/26/23 06:27, Vinnie Falco wrote:

On Sat, Nov 25, 2023 at 6:17 PM Andrey Semashev via Boost 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