{"id":47068,"date":"2025-03-13T15:52:03","date_gmt":"2025-03-13T19:52:03","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=47068"},"modified":"2025-03-13T15:52:52","modified_gmt":"2025-03-13T19:52:52","slug":"swift-proposal-import-objective-c-completion-handler-parameters-as-sendable","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/03\/13\/swift-proposal-import-objective-c-completion-handler-parameters-as-sendable\/","title":{"rendered":"Swift Proposal: Import Objective-C Completion Handler Parameters As @Sendable"},"content":{"rendered":"

SE-0463<\/a>:<\/p>\n

The @Sendable<\/code> annotation indicates that closure parameters are passed over an isolation boundary before they’re called. A missing @Sendable<\/code> annotation in a library has negative effects on clients who call the function; the caller can unknowingly introduce data races, and SE-0423: Dynamic actor isolation enforcement from non-strict-concurrency contexts<\/a> injects runtime assertions for non-Sendable<\/code> closure parameters that are passed into libraries that don’t have data-race safety checking. This means that a missing @Sendable<\/code> annotation can lead to a runtime crash for any code that calls the API from an actor isolated context, which is extremely painful for projects that are migrating to the Swift 6 language mode.<\/p>

There’s a large category of APIs with closure parameters that can be automatically identified as @Sendable<\/code> functions, even if the annotation is missing: Objective-C methods with completion handler parameters. @Sendable<\/code> is nearly always the right default for Objective-C completion handlers, and programmers have already been searching for an automatic way for completion handlers to be @Sendable<\/code> by default when auditing Clang headers<\/a>.<\/p>

[…]<\/p>

If a completion handler does not cross an isolation boundary before it’s called, the parameter can be annotated in the header with the @nonSendable<\/code> attribute using __attribute__((swift_attr(\"@nonSendable\")))<\/code>.<\/p>

[…]<\/p>

Changing this proposal later to use sending<\/code> instead will pose source compatibility issues, because it would become invalid to have a protocol requirement that is imported with a sending<\/code> completion handler and implement the requirement with a @Sendable<\/code> completion handler. The same source compatibility issue exists for overridden class methods.<\/p><\/blockquote>\n\n

Previously:<\/p>\n