Boost logo

Boost :

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2024-03-27 15:31:02


On Wed, Mar 27, 2024 at 9:47 PM Vinnie Falco via Boost
<boost_at_[hidden]> wrote:
>
> I guess I'm confused. My understanding is that libraries are considered
> good candidates for the Boost collection based on meeting some or all of
> certain criteria:
>
> * They offer useful, novel functionality not found elsewhere
> * The API is superior to other libraries that do similar things
> * The implementation is exceptionally performant
> * Solving a familiar problem in a particularly elegant fashion
> * The library is already popular and has field experience
> * The library offers C++ standard functionality for older compilers
>

If by "My understanding is" you mean to imply that those are general
rules, you are mistaken. I know for a fact that the latter two would
not get consent.

Especially your criteria for popularity & field experience seems wrong
to me. Let's just take boost.json: that would have gotten my
endorsement with zero users, because it's just obviously a useful
thing to have.

Also, why does it need to be exceptional? If there were amazing json
libraries and boost.json was just better in it's error handling and a
better fit for boost it wouldn't be exceptional? Why would that hurt
inclusion into boost?

You can have your preferences and thus withhold an endorsement and
recommend rejection during the review.

> But some of the chatter on the mailing list suggests that the bar for a
> Boost library candidate is lower. That a library just needs to basically
> work, even if it duplicates functionality found elsewhere, or even if it
> does not have anything that one might hold up as an example of exceptional
> engineering.

Correct. Being a candidate gives the library author the opportunity to
receive feedback and prepare for the actual review.
Given that preparing for the boost review includes a lot of work that
is only useful if the library gets accepted into boost,
I find it a good idea to receive an endorsement early.

>
> Boost libraries used to be cutting edge, to such an extent that they were
> adopted into the C++ Standard. And now the progress is in reverse. The
> Standard introduces a new component, and the Boost library follows
> (Boost.Charconv for example). In other cases I see libraries with few to no
> users limping into reviews, or absent discussions which question whether or
> not the bar for excellence is exceeded. When I used to participate in wg21
> I complained about the "direct to standard" pipeline, where people would
> just write papers for the sake of it with no example code or real-world
> user experience. I have to wonder if we are not cultivating a "direct to
> Boost" pipeline by having relaxed or poorly-defined acceptance criteria.
>

It sounds like you'd like boost to be cutting edge yet have libraries
that have field experience and a user base. Pick one.

[...]

>
> When I look at a proposed library I try to figure out what is great about
> it, how well it performs for its users (or even, does it have any users?),
> what part of the API is exceptionally well designed and ergonomic, but most
> importantly I want to ask: what makes this library stand out to the extent
> that it should be part of the library collection? What aspects of the
> library, if viewed by someone learning C++ or interested in improving their
> design skills, are inspirational?
>

Again, why does a library need to stand out?
Why isn't it good enough to solve a real world problem in an excellent fashion?
Why does it need to be exceptional, which implies it eclipses all competitors?

> Is this overly demanding or exclusionary? Am I overthinking things? Should
> we be asking more of these types of questions and requiring better answers?
>

You should ask more targeted questions and accept answers.
In case of the sqlite discussion your question was "Why isn't this
more like SoCi?".

You completely ignored me pointing out the category mistake and
all the features sqlite has that set it apart from any other sqlite
client library.

I think category mistakes and lack of understanding of scope can lead
to many frustrating discussions here.
I am pretty sure that you're familiar with people asking why beast is
such a complicated version of python's request.

The same happened during the mysql, redis and mustache reviews.

I think it's important to ask two questions:

1. Based on the scope the author chose, does this library make sense in boost?
2. Is the execution great?

I don't think it's illegal to question the scope, but it's usually not helpful.
The author usually has a good idea what should be in a library, like
you limiting boost.json to not include other document formats, because
a user can just provide his own parser.
It's a choice that makes sense, so both criteria are fulfilled.

I think a lot of tension arises when people don't consider the
intended scope of a library, but rather assume the library's scope
must be congruent with their use-case.

> What is the criteria for determining if a library is good enough to become
> part of the collection?

It passes review. That's the criteria, and always will be.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk