Swift Proposal: Import Objective-C Completion Handler Parameters As @Sendable
The
@Sendableannotation indicates that closure parameters are passed over an isolation boundary before they’re called. A missing@Sendableannotation 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 injects runtime assertions for non-Sendableclosure parameters that are passed into libraries that don’t have data-race safety checking. This means that a missing@Sendableannotation 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.There’s a large category of APIs with closure parameters that can be automatically identified as
@Sendablefunctions, even if the annotation is missing: Objective-C methods with completion handler parameters.@Sendableis 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@Sendableby default when auditing Clang headers.[…]
If a completion handler does not cross an isolation boundary before it’s called, the parameter can be annotated in the header with the
@nonSendableattribute using__attribute__((swift_attr("@nonSendable"))).[…]
Changing this proposal later to use
sendinginstead will pose source compatibility issues, because it would become invalid to have a protocol requirement that is imported with asendingcompletion handler and implement the requirement with a@Sendablecompletion handler. The same source compatibility issue exists for overridden class methods.
Previously:
- Swift 6.1
- Swift Vision: Improving the Approachability of Data-Race Safety
- Swift Concurrency and Objective-C
