Support async calls in defer bodies

[jamieQ (Jamie)]

+1 for the feature – thanks for pushing it! i think the proposed decisions are the right ones as i feel they extend support for async expression handling to defer statements in the most 'natural' way^[1]. like others have expressed earlier, i also think the questions around 'cancellation shields' and error handling are separable and shouldn't block the proposed improvement here.

@Jumhyn

The body of a defer statement will always inherit the isolation of its enclosing scope, so an asynchronous defer body will never introduce additional suspension points beyond whatever suspension points are introduced by the functions it calls.

thanks for explicitly stating this – i also see that Holly drew attention to it in the current implementation PR, but i wanted to reiterate that we should try to avoid inadvertently introducing more surface area for surprise isolation crossings; e.g. like the one withTaskCancellationHandler currently has which can introduce suspension points due to its interaction with closure isolation inference rules. put another way, async defer bodies should definitely have nonisolated(nonsending) semantics.

---

1. if you were relatively new to swift, understood defer and async then i think this is exactly how you'd expect the composition of the features to behave. ↩︎