On Thu, 13 Apr 2023, 16:28 Ville Voutilainen via Std-Discussion, <
std-discussion_at_[hidden]> wrote:

> On Thu, 13 Apr 2023 at 22:01, Jason McKesson via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
>
> > 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.
>

Absolutely.

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?

>