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

From: Jeff Garland (azswdude_at_[hidden])
Date: 2023-11-28 16:06:52

On Sat, Nov 25, 2023 at 8:27 PM Vinnie Falco via Boost <
boost_at_[hidden]> 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.
>

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