On Thu, 13 Apr 2023 at 22:01, Jason McKesson via Std-Discussion
> Considering how difficult it is to answer the basic question in
> coroutines without an explicit `try` block... maybe we should just not
> support these things? Maybe we should just encourage people to use
> `try/catch` blocks if they need to check for scope failure. Yes, it's
> not as visually pleasing, but it solves the problem.
That solution doesn't work, because you can exit scopes with return,
break, and goto as well,
and the whole point of these scope guards is that they are able to run
their cleanup regardless
of how you do the scope exit. And for scope_fail, its purpose is
specifically that you don't
have to catch and rethrow if your function doesn't want to handle
exception. So that's
a complete non-solution.
Warning users that these things don't work in coroutines seems like a
palatable solution to me.
It seems like a non-solution to me. Users will do it anyway, then get confused and complain when it doesn't work. Coroutine libraries will come up with solutions like the above, but independently and without interoperability, so if you're using the folly scope guards you have to use folly coroutines and vice versa, and the same for boost etc.
The thing is, it is possible for scope guard destructors to detect how they were called. We just have to give up composability, which honestly doesn't seem like that much of an issue - why would you want to put a scope guard inside another object or in dynamic storage?