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

niedz., 26 lis 2023 o 04:27 Vinnie Falco via Boost napisał(a):

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.

...

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.

Maybe this argument applies with different weight for vocabulary and non-vocabulary types. My understanding of a vocabulary type is that it is one that you would likely expose in your interfaces, and have two (or more) libraries communicate via it. optional, shared_ptr, variant, error_code are types of this sort. For those types you would strongly prefer to use the std version, because it is likely that other 3rd party libraries will also use the std version. scope_guard is a type you will use internally in your implementation, so whether you pick the Boost version or the std version is your private business. Regards, &rzej;

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost