Re: [scope] Looking for endorsements and review manager

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-10-09 16:27:25

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.