Re: [Scope] Peer review conclusion

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-01-15 21:12:01

On 1/15/24 22:50, Дмитрий Архипов via Boost wrote:
> 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.

As a potential option, we could split the library in two git modules,
one with scope guards and another one with unique_resource. This would
count as two libraries, so I'm not sure if this would be an acceptable
result of the review, but if people want this, I wouldn't mind.

Dmitry, please let me know if this is desired, so that I make the split.
Name suggestions are also welcome.

> 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.

Thank you Dmitry for managing the review and, of course, to everyone who
provided their feedback, especially in the form of reviews.

I will work on addressing the review comments and conditions and will
post separately when I think I'm done.