[boost] [scope] Looking for endorsements and review manager

[Andrey Semashev via Boost]

Hi,

This is a reminder that Boost.Scope is looking for endorsements and a
review manager. Following is an excerpt from the previous announcement,
describing the library.

Boost.Scope is a small library implementing utilities defined in
<experimental/scope> from C++ Extensions for Library Fundamentals v3
with a few extensions. Namely, the library contains:

* A number of scope guards for various use cases.
* A unique resource wrapper that automatically frees the resource on
destruction.
* Utilities for wrapping POSIX-like file descriptors in the unique
resource wrapper.

Compared to <experimental/scope>, some notable extensions are:

* A new scope_final scope guard, which is a more lightweight alternative
to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that
allows to simplify scope guard declaration syntax.
* Scope guards can be activated/deactivated multiple times.
* Scope guards can be created inactive initially.
* Scope guard factory functions, for compatibility with C++11.
* Support for optional resource traits in unique_resource wrapper, which
improves usage with resources having unallocated values.
* unique_resource supports swapping.
* unique_resource supports dereferencing for any resource types that
support dereferencing, not only pointers.
* More flexible constructors for unique_resource.

The library requires C++11 at the minimum and will significantly benefit
from C++17.

Source:

https://github.com/Lastique/scope

Docs:

https://lastique.github.io/scope/libs/scope/doc/html/index.html

The library is tested in CI and used in production in one of my projects.

Thanks.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Mazakas via Boost]

I'll endorse this library for inclusion into Boost.

It's small so it'll be easy to package for managers like vcpkg and Conan.

It solves a problem common to almost all C++ development.

I believe these two reasons alone are compelling enough to endorse this library.

However, I don't have the bandwidth to manage the review so that'll
have to fall to someone else.

- Christian

[Andrey Semashev via Boost]

On 9/27/23 19:13, Christian Mazakas via Boost wrote:
> I'll endorse this library for inclusion into Boost.
>
> It's small so it'll be easy to package for managers like vcpkg and Conan.
>
> It solves a problem common to almost all C++ development.
>
> I believe these two reasons alone are compelling enough to endorse this library.
>
> However, I don't have the bandwidth to manage the review so that'll
> have to fall to someone else.

Thank you for the endorsement.

[Alan de Freitas via Boost]

Hi Andrey,

Thanks for the reminder about Boost.Scope. I endorse the library.

Em qui., 21 de set. de 2023 às 11:03, Andrey Semashev via Boost <
bo...@lists.boost.org> escreveu:

--
Alan Freitas
https://alandefreitas.github.io/alandefreitas/
<https://github.com/alandefreitas>

[Andrey Semashev via Boost]

On 9/27/23 19:59, Alan de Freitas via Boost wrote:
> Hi Andrey,
>
> Thanks for the reminder about Boost.Scope. I endorse the library.

Thank you.

[Дмитрий Архипов via Boost]

I endorse the library and propose myself as the review manager.

чт, 21 сент. 2023 г. в 17:03, Andrey Semashev via Boost <bo...@lists.boost.org>:

[Andrey Semashev via Boost]

On 10/4/23 21:00, Дмитрий Архипов via Boost wrote:
> I endorse the library and propose myself as the review manager.

Thank you for the endorsement and the offer to be the review manager.
I'm happy to accept the offer.

[Peter Dimov via Boost]

Andrey Semashev wrote:
> Source:
>
> https://github.com/Lastique/scope
>
> Docs:
>
> https://lastique.github.io/scope/libs/scope/doc/html/index.html

Question:

What is the difference between scope_check<F, C>,
scope_success<F, C> and scope_fail<F, C>? Why do we need the
second template parameter of the latter two if scope_check is
provided?

Wouldn't it be clearer if scope_success and scope_fail took a
single F parameter?

Also, wouldn't it be better if scope_exit took a second parameter
C defaulting to "always" instead of having scope_check?

[Andrey Semashev via Boost]

On 10/9/23 18:33, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> Source:
>>
>> https://github.com/Lastique/scope
>>
>> Docs:
>>
>> https://lastique.github.io/scope/libs/scope/doc/html/index.html
>
> Question:
>
> What is the difference between scope_check<F, C>,
> scope_success<F, C> and scope_fail<F, C>? Why do we need the
> second template parameter of the latter two if scope_check is
> provided?
>
> Wouldn't it be clearer if scope_success and scope_fail took a
> single F parameter?

The second template parameter is the failure condition checker. It
exists to allow for checking for different kinds of failure, other than
whether there is an exception in flight. I wanted to support checking
for error_codes and similar as an alternative to exceptions.

For scope_success and scope_fail that template parameter is optional.
The class templates exist because they were defined in the Fundamentals
TS (although there the second template parameter is not present and the
scope guards always unconditionally check for exceptions).

scope_check is a generalization of scope_success and scope_fail. It does
not assume exceptions and requires the user to provide his failure
condition predicate. Other than that, it's functionally equivalent to
scope_fail. If I was designing the library with no relation to the TS, I
would probably only provide scope_check.

I think, there is still a small value in having scope_success and
scope_fail, since they make the common use case with exceptions a bit
more concise. But the main reason for their existence is that I want to
provide the scope guard names that are defined in the TS.

> Also, wouldn't it be better if scope_exit took a second parameter
> C defaulting to "always" instead of having scope_check?

Do you mean to effectively rename scope_check to scope_exit, and add a
default predicate that always returns true?

I suppose, it is possible, although currently scope_exit is a bit more
lightweight than scope_check. The latter is more complicated because the
implementation should be prepared for the failure condition predicate
constructor to throw. Perhaps, that is a good idea, if that extra
overhead is not considered as a problem.

[Peter Dimov via Boost]

I don't think this answers my question. I agree that scope_success<F>
and scope_fail<F> need to be provided. I'm asking why we need
scope_success<F, C> and scope_fail<F, C>, because it seems to me that
one of these is exactly equivalent to scope_check<F, C> and the other
is the same with the condition reversed.

[Andrey Semashev via Boost]

Mostly for completeness (i.e. to support arbitrary failure conditions in
all checking scope guards) and because it doesn't cost anything. I don't
see the value in restricting scope_success and scope_fail to just
exceptions.

In other words, if I compare the current implementation with two
template parameters and a potential implementation with one, the former
is more flexible, but other than that I see no difference. With all
other things being equal, more flexible = more better.

[Andrey Semashev via Boost]

On 10/9/23 19:27, Andrey Semashev wrote:
> On 10/9/23 18:33, Peter Dimov via Boost wrote:
>> Andrey Semashev wrote:
>>> Source:
>>>
>>> https://github.com/Lastique/scope
>>>
>>> Docs:
>>>
>>> https://lastique.github.io/scope/libs/scope/doc/html/index.html
>>
>> Question:

[...]

>> Also, wouldn't it be better if scope_exit took a second parameter
>> C defaulting to "always" instead of having scope_check?
>
> Do you mean to effectively rename scope_check to scope_exit, and add a
> default predicate that always returns true?
>
> I suppose, it is possible, although currently scope_exit is a bit more
> lightweight than scope_check. The latter is more complicated because the
> implementation should be prepared for the failure condition predicate
> constructor to throw. Perhaps, that is a good idea, if that extra
> overhead is not considered as a problem.

I have now merged scope_check into scope_exit, as you suggested. There
is already a lightweight scope_final guard, so making scope_exit more
feature-rich seemed like a good idea. Thanks for the suggestion.

Also, for anyone interested, I have created a single-header version of
the library that is compatible with godbolt.org:

https://godbolt.org/z/6rvhnTrvn

Feel free to try it online.

PS: The single-header version is not part of the library, as proposed
for inclusion into Boost. It's just to simplify the review process.

[Peter Dimov via Boost]

Andrey Semashev wrote:
...

> >>> Source:
> >>>
> >>> https://github.com/Lastique/scope
> >>>
> >>> Docs:
> >>>
> >>> https://lastique.github.io/scope/libs/scope/doc/html/index.html

...

> I have now merged scope_check into scope_exit, as you suggested. There
> is already a lightweight scope_final guard, so making scope_exit more
> feature-rich seemed like a good idea. Thanks for the suggestion.

In principle, the implementation can specialize scope_exit for the
default case of always_true, so it doesn't have to be any less efficient
than before.

[Andrey Semashev via Boost]

On October 15, 2023 8:17:10 PM Peter Dimov via Boost

<bo...@lists.boost.org> wrote:

> Andrey Semashev wrote:
> ...
>>>>> Source:
>>>>>
>>>>> https://github.com/Lastique/scope
>>>>>
>>>>> Docs:
>>>>>
>>>>> https://lastique.github.io/scope/libs/scope/doc/html/index.html
> ...
>> I have now merged scope_check into scope_exit, as you suggested. There
>> is already a lightweight scope_final guard, so making scope_exit more
>> feature-rich seemed like a good idea. Thanks for the suggestion.
>
> In principle, the implementation can specialize scope_exit for the
> default case of always_true, so it doesn't have to be any less efficient
> than before.

Yes, I thought so too. I even had the idea of making void the default and
specialize for that. But the current implementation should be efficient as
well, although it requires more template machinery to eliminate the runtime
overhead. It might affect compile times though.

[Дмитрий Архипов via Boost]

The review for Scope has been scheduled to take place November 26,
2023 - December 5, 2023
with me as the review manager. This will be a week after the next
release (1.84).
Hopefully everyone will have time to get some rest and join the review.

вс, 15 окт. 2023 г. в 22:30, Andrey Semashev via Boost <bo...@lists.boost.org>: