Boost logo

Boost :

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-05-31 09:29:36


>
>
> Please provide in your review information you think is valuable to
> understand your choice to ACCEPT or REJECT including LEAF as a
> Boost library. Please be explicit about your decision (ACCEPT or REJECT).
>

*Review:*

*Introduction:*

This is my first review of a boost candidate library. Anyone who has done
the work in order to write, document and present a library for inclusion is
already in my view far more authoritative than me, a mere maintainer.

This review pivots on the question of, "what is the purpose of Boost?"

a) A collection of high quality libraries that meet the needs of
demonstrated use cases, or
b) A high quality sandbox for ideas that may eventually influence the
direction of the language or the standard library.

In the past, I think it has been both. Which has been a source of both
criticism and praise across the user spectrum.
Boost seems to me the "Marmite*" of the C++ user community - people either
hate it on grounds of "bloat" or love it on grounds of quality, usefulness
and being a source of inspiration.

All Boost libraries share a common trait, which is that the authors are
feidishly clever people, with insights beyond those of an above-average
developer,
Many Boost libraries brilliantly answer (or answered in the past)
demonstrable use cases. Some examples of these (off the top of my head) are:
Asio, Beast, Spirit, Container, Mpl, Mp11, Smart Pointer, Bimap, Multi
Index, Regex, and many others.

Some Boost libraries are brilliantly clever and I often wish that either I
had a use case for them, or could be bothered to do the work needed order
to use them:
Hana, Units, Type Erasure and so on.

Each library we add to Boost represents maintenance overhead for the people
who give their time in order to ensure that releases are seamless and
professional. So in a sense, each Boost library added ought to at least
offer some credible payoff for a significant subset of Boost users, future
or present.

*The task at hand:*

> - What is your evaluation of the design?
>

* LEAF represents a comprehensive error handling strategy which seeks to
encapsulate the strengths of all others.

> - What is your evaluation of the implementation?
>

* I personally find the lambda-based pattern-matching handler code to be
utterly impenetrable. I accept that it is solving a problem that is beyond
the scope of the language in which it is written, and this has a cost in
terms of readability and accessibility to a (LEAF) novice.

> - What is your evaluation of the documentation?
>

* LEAF is well documented and is maintained and presented by a motivated
and responsive author.

> - What is your evaluation of the potential usefulness of the library?
>

* I have not seen a credible use case articulated or demonstrated to me.
This in my mind, puts leaf in category b, "A high quality sandbox for ideas
that may eventually influence the direction of the language or the standard
library."

> - Did you try to use the library? With which compiler(s)? Did you
> have any problems?
>

Godbolt, gcc. No problems.

> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
>

In depth study, questions to the author around some implementation details
and use cases.

> - Are you knowledgeable about the problem domain?
>

Yes

And so to the final question. ACCEPT or REJECT?

It's a difficult call, and the answer depends on what is our consensus on
the purpose of Boost.

a) A collection of high quality libraries that meet the needs of
demonstrated use cases, or

In this case, brilliant as it is, I have not yet seen an example of a
motivating use case sufficuently compelling to say ACCEPT.
In which case the added workload of a new, cryptic library that represents
a paradigm shift in the way people think about errors and is therefore
unlikely to be used very much indicates an answer of REJECT.
With an important footnote to the effect that once there is some
demonstrated *de facto* user traction or compelling presentation of use
case where LEAF clearly outperforms existing methods, I would switch to
ACCEPT.

b) A high quality sandbox for ideas that may eventually influence the
direction of the language or the standard library.

In this case, LEAF would demonstrate value at the present time, and my
recommendaton, on grounds of quality, would be ACCEPT, even though I'll
probably never use it.

*Summary:*

My apologies to my colleagues, I am in need of some direction before I can
make my final recommendation.

Are we today in camp A or camp B? In the light of your guidance, my answer
is:

if A, REJECT (happy to revisit in the light of *de facto* traction or
convicing use case)
if B, ACCEPT

Regards,

R

* Marmite is the brand name of a black yeast derivative that is sold in
jars in the UK. The country is divided as to whether it is revolting or
delicious. The manufacturer's TV advertising efforts famously capitalised
on this conflict.

>
> More information about the Boost Formal Review Process can be found
> here: <http://www.boost.org/community/reviews.html>
>
> Thank you for your effort in the Boost community.
>
> Happy coding -
> michael
>
> --
> Michael Caisse
> Ciere Consulting
> ciere.com
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: +442032898513
home: +376841522
mobile: +376380212

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