[Pitch] Import Objective-C completion handler parameters as `@Sendable`

[hborla (Holly Borla)]

Hello, Swift evolution!

I wrote up a pitch for importing Objective-C completion handler parameters as @Sendable by default. The idea is pretty straightforward - the Objective-C interoperability heuristic that identifies completion handler parameters for importing async functions will also include @Sendable annotations by default on the completion handler parameter.

This idea has come up a number of times on the forums already, most recently in https://forums.swift.org/t/how-to-fix-a-crash-in-secaddsharedwebcredential-under-swift-6/77806/3:

@KeithBauerANZ

This is a real problem with the clang importer and Swift 6 — importing ObjC closures without @Sendable is no longer a conservative choice.

The above forum discussion demonstrates the real-world impact of a missing @Sendable annotation, which is the motivation behind this pitch.

Please leave design feedback in this pitch thread, and leave editorial feedback on the swift-evolution PR at Proposal: Import Objective-C completion handler parameters as `@Sendable`. by hborla · Pull Request #2694 · swiftlang/swift-evolution · GitHub.

I look forward to your questions, thoughts, and other constructive feedback!

-Holly

[KeithBauerANZ (Keith Bauer)]

Thank you!

I'm sure this will add a bunch of warnings to everyone's code, but probably mostly genuine ones, and I don't see a better option...

Perhaps a hole should be carved out where @MainActor methods' completion handlers are presumed @MainActor, rather than @Sendable? It's not always true, but maybe true enough to consider?

[tclementdev]

+1 Makes sense. This change is the right default for when the objc interface isn't annotated. We really shouldn't assume non-sendable behavior in this case. The current situation causes a good number of crashes in real world code migrating to Swift 6 so definitely a welcome change.

[grynspan (Jonathan Grynspan)]

Yes please!

[ksluder (Kyle Sluder)]

Is there another heuristic that infers @MainActor for completion handler methods on MainActor-isolated types, or am I misremembering?

[hborla (Holly Borla)]

@KeithBauerANZ

Perhaps a hole should be carved out where @MainActor methods' completion handlers are presumed @MainActor, rather than @Sendable? It's not always true, but maybe true enough to consider?

I think this is a great idea for a carve out. I suspect this will avoid a significant number of false positive warnings. And because this will only apply in cases where the closure parameter is non-@Sendable today, it's not going to add any new dynamic assertions anyway. In the worse case, if we find that actually most @MainActor-isolated methods with completion handlers in practice should take @Sendable closures (which I doubt is the case), we can later extend the rule in this proposal to those methods as well.

@ksluder

Is there another heuristic that infers @MainActor for completion handler methods on MainActor-isolated types

No, but this happens to be true in many cases because of the rule that non-@Sendable closures are isolated to whatever context they're formed in. For @MainActor-isolated completion handlers, they're nearly always called in a @MainActor-isolated context (because if you were not in a @MainActor-isolated context, the call would have to be async and you're better off just using the async variant), so the closure is isolated to the main actor due to the non-@Sendable rule.

[grynspan (Jonathan Grynspan)]

@hborla

@KeithBauerANZ

Perhaps a hole should be carved out where @MainActor methods' completion handlers are presumed @MainActor, rather than @Sendable? It's not always true, but maybe true enough to consider?

I think this is a great idea for a carve out.

Should we broaden the rule to any global actor, not just @MainActor? I realize the use of other global actors in Objective-C probably isn't expected to be common, but with custom serial executors it may well be more common than we realize.