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

On Sat, Nov 25, 2023 at 8:27 PM Vinnie Falco via Boost < boost@lists.boost.org> 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.

Agree with this.

...

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 think the canonical example actually is boost::thread. It had an interruption feature -- and maybe some other things I've forgotten -- that come up often. Probably now solved by jthread in c++20, but possibly not as cleanly. shared_ptr may be a similar case although recent std additions from Peter and friends may have closed the gap.

....

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.

I haven't studied the scope additions compared to the TS yet, but it seems unlikely to get to the proposed bar. Perhaps there's a middle ground where the library can offer opt-in extensions but otherwise adhere to the standard interface? One good reason I can see in this case is that the Scope facilities are currently *only in a technical spec*, so if there's something compelling that's missing that could be changed before it's proposed for the standard. Getting some experience with that sort of thing is very valuable to making the standard better in the first place. For those that wanted to try the extensions the opt-in makes it clear that it's not going to match what we're guessing will go into the standard.

...

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.

Also very much agree with this... Jeff