[Accepted] SE-0424: Custom isolation checking for `SerialExecutor`

Hello, Swift community.

The review of SE-0424: Custom isolation checking for SerialExecutor ran from February 22nd through March 4th, 2024. Feedback was light but positive on the general idea.

A question was raised during the review about the design of the new checkIsolation requirement. Specifically, this requirement is specified to trap when the current context does not have the right isolation; there's no way to simply test the current isolation. This matches the current isolation-testing features in the concurrency runtime, such as assumeIsolated, but it wouldn't work for potential future features such as actor.whenIsolated { ... }. The Language Steering Group considered this issue and decided that we're comfortable with leaving that as a feature direction — if we add an API like whenIsolated in the future (which is far from certain), we can add a new requirement then. But it's noteworthy that Dispatch (the most prominent custom executor implementation in the Swift ecosystem) would not be able to implement that requirement with its current public API, making that a pretty unreliable feature to use with an unknown executor. If an actor knows that it uses an executor that supports a boolean-testing API, it can provide its own, concrete whenIsolated API without relying on the standard library.

Accordingly, SE-0424 is accepted.

I'd like to thank the reviewers for their contributions to Swift. As always, open evolution review is an instrumental part of making Swift a better language.

John McCall
Review Manager


Drats, I was a day late with my response on the review thread, just prior to the announcement of the approval + thread close.

Has the LSG had a chnce to consider that, or did I "miss the boat," so to speak?

Not speaking for core team (since I’m not on it :sweat_smile: bur figured I’ll clarify) but just myself here as proposal author — for what it’s worth an api like this doesn’t help us much. The moment “most implementations will crash rather than return” you can’t consistently build functionality on it that REQUIRES the true/false reply. It was worth bringing up, thank you, but I don’t think it affects the design.

If we end up in a place where we really need the Boolean api we’d better be able to implement it on major adopters, or we would not be able to build reliably on top of it.


Good point!

And even though Dispatch might feel like a niche case (in that's it's just one case), it's not actually niche, because it's likely to be the majority of uses. So yeah, most implementations realistically would be crashing.

Thanks for taking the time to chime in :)