Re: [scope] scope_fail is unimplementable

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-04-07 16:15:33

On 4/7/23 19:04, Andrzej Krzemienski wrote:
> 
> 
> pt., 7 kwi 2023 o 17:43Â Andrey Semashev via Boost <boost_at_[hidden]
> <mailto:boost_at_[hidden]>> napisał(a):
> 
>     On 4/7/23 15:55, Andrzej Krzemienski wrote:
>     >
>     > This is not true when a scope guard is used across coroutine
>     > suspensions: by default [...] scope_fail is not destroyed due to
>     > exception being thrown. The reality is, it is destroyed based on the
>     > comparison of two measurements of the number of uncaught exceptions,
>     > potentially measured in different threads.
>     >
>     >Â  Â  Â I admit this is a notable limitation, and I will document it.
>     But I do
>     >Â  Â  Â not consider this limitation fatal, as there is plenty code
>     out there
>     >Â  Â  Â that doesn't use coroutines - I'd even say, much more code
>     than that
>     >Â  Â  Â does.
>     >
>     > This is one way of looking at it: that the problem is rare. A
>     different
>     > way is to say that if something works in 99% of the cases and
>     fails only
>     > in 1%, we have a dangerous situation, as we are unprepared when the 1%
>     > case happens.
> 
>     Well, every technology has its limits. And if a utility is not usable in
>     1% of use cases, I don't see why it shouldn't exist to benefit the
>     rest 99%.
> 
> Let me clarify my point here a bit. We can distinguish two situations
> here. The first is this. A tool compiles and works fine in 99% of the
> cases, and in the remaining 1% it fails to compile, or signals an error.
> The second is this. A tool compiles and works fine in 99% of the cases,
> and in the remaining 1%it compiles fine, reports no error, and works
> against the user's expectations or the declared intent.
> 
> In the first case, this is an acceptable trade-off. In the second case,
> it may be debatable, but I personally would find it a bad trade-off. My
> claim is that the situation with scope_fail is closer to the second one.
> Especially, given that a 100% alternative exists: just explicitly
> deactivate an active guard.

If there was a way to trigger a compilation error in the problematic
case, I would gladly use it. Let me know if there is one.

In the absence of such a way, I still prefer to have the tool compared
to not having it, for the cases not involving coroutines. And the
ability to deactivate the guard is still there, should you prefer to use
it in the problematic case.