On Fri, 7 Apr 2023 at 18:54, Andrey Semashev via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
On 4/8/23 01:49, Thiago Macieira via Std-Discussion wrote:
> On Friday, 7 April 2023 14:31:46 -03 Andrey Semashev via Std-Discussion wrote:
>> I think this issue needs to be addressed in the TS before inclusion into
>> the main standard. As a possible solution, I proposed the following idea:
>
> The standard solution does not need your suggested implementation details. It
> just needs to describe the expected behaviour and require that the
> implementations do it properly. They may have other means of achieving the
> same result.

Sure, the standard may simply require a certain behavior, and I did not
intend my proposed solution to be adopted or even be part of the
standard wording. I simply indicated that there is a way to achieve
this, which is something that is welcome for any proposal, isn't it?

The point is, the current TS wording explicitly mentions
unhandled_exceptions(), and it should not. Instead, it should describe
the required behavior, including when used in conjunction with
coroutines. Though I would still prefer if the behavior was
implementable using the standard library API so that non-standard scope
guard libraries like Boost.Scope could be implemented without resorting
to compiler-specific intrinsics or private APIs.

Your putative co_unhandled_exceptions() sounds like it would have pretty substantial overhead - an extra word-sized counter per coroutine, and the overhead of updating it whenever you resume a coroutine. It's a big ask compared to the plain unhandled_exceptions(), which is one word per thread and only updated when exceptions are thrown/caught, so lost in the noise.

I think it's a lot more likely that compilers will just create types whose destructors are marked as being called only either from scope exit or from unwind cleanup, and omitted in the other case. (At least, that's how I'd implement it.) So Boost.Scope etc. will need to either use those magic library types, or the attributes/intrinsics those library types use (if they aren't implemented with True Name magic).

I agree with Thiago that it's more important to establish what the correct behavior is around coroutines, so we can get it into wording as examples and as the basis of Library tests.