Re: [scope] Looking for endorsements and review manager

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

On 10/9/23 19:35, Peter Dimov via Boost wrote:
> 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:
>>>
>>> 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.
> 
> 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.

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.