|
Boost Users : |
From: ÐмиÑÑий ÐÑÑ
ипов (grisumbras_at_[hidden])
Date: 2024-01-15 20:06:19
Dear Boost community, the formal review of Boost.Scope has taken place between
26th of November and 5th of December of the previous year. I have received 5
reviews in total, including 4 here on the mailing list and 1 on Reddit. Two of
the reviews recommended unconditional, and 3 conditional acceptance. The
reviews came from:
- Klemens Morgenstern,
- Janko Dedic,
- Julien Blanc,
- David Sankel,
- /u/jonesmz on Reddit.
Also, several people have given insightful comments but did not provide a
review. I would like to thank all of the people who took their time to write
reviews or participate in the discussions. Your effort was very important and
valuable.
The outcome of the review is that Boost.Scope is ACCEPTED with several minor
CONDITIONS.
1. noexcept specification on destructors of scope guards should be properly
documented. Andrey has already commented that the technical hurdle that
prevented it was eliminated.
2. There should be a good motivating example for scope_success. There was a lot
of comments regarding scope_success and its seeming uselessness. Without a
good example I see the same pattern occurring with future users.
3. The examples should better describe what they are trying to achieve. Several
comments about examples suggested incorrect changes, which signals that readers
failed to understand them.
After a lot of consideration I decided against requesting the author to remove
unique_resource and related functionality from the library. While several
reviewers wanted a more "concise" library, all noted that the component is
useful.
One last thing I wanted to point out is that all reviewers and most commenters
were adamant that compatibility with the Technical Specification on which this
library was initially based should not be a goal. In fact, Andrzej Krzemienski
even noted that such compatibility has prevented him from adequately evaluating
the library on its own merit. In my opinion this should be a sign to all of us
that people prefer better APIs over standard APIs. I recommend Andrey to
re-evaluate those parts of the library's APIs that he copied from the TS and
potentially pick better names for member functions.
Thanks to Andrey for submitting this library to Boost. And thanks again to the
reviewers and everyone who provided feedback, who ultimately made this review
possible.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net