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

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, scope_success and scope_fail? 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 and scope_fail, because it seems to me that one of these is exactly equivalent to scope_check 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.