[Accepted] SE-0418: Inferring Sendable for methods and key path literals

Hello Swift community,

The review of SE-0418: Inferring Sendable for methods and key path literals ran from December 14, 2023...January 1, 2024.

Feedback was light and focused on clarifying the proposal's scope and its interactions with other features. The steering group noted that the proposal is a little vague about the specifics of the new appending(path:) overloads, but the open questions concern issues like back deployment that are not within the scope of evolution reviews. Other than that, the review did not identify any cause for concern, so the Language Steering Group has chosen to accept the proposal.

Thank you all for your participation in this discussion!

Becca Royal-Gordon
SE-0418 Review Manager


I’m sorry for being late to the party, but I think I see an issue in the proposal.

For unapplied methods, sendability of the nominal type should affect sendability of result type, but not the unapplied method itself. Unapplied method, being a global function, is always sendable:

class A {
    func foo(String) -> Bool
struct B: Sendable {
    func foo(String) -> Bool

let a: @Sendable (A) -> (String) -> Bool = A.foo
let b: @Sendable (B) -> @Sendable (String) -> Bool = B.foo

Yes, you're right. The implementation of InferSendableFromCaptures already behaves this way, so if the proposal says otherwise, I think it's a mistake.

1 Like

Found a fun bug potentially related to this proposal, Sendability incorrectly inferred for curried method · Issue #70829 · apple/swift · GitHub

I think the bug here is that point 5 in the proposal is not being enforced:

1 Like

Oh you're right @beccadax. It looks like this rule is only enforced for non-async functions.

Actually async and non-async methods should be handled by Pull Request #69220 !



SE-0418 is marked as implemented in Swift 6.0.

However, it also has an upcoming feature flag defined.

Wouldn't adjusting to the source incompatibilities introduced with this proposal be part of migrating to the Swift 6 language mode?

Or is the upcoming feature flag still needed because the functionality will be in Swift 6.0, even if it is running under Swift 5 language mode? (And would therefore enable the Swift 6 language mode behavior?)

Thank you!

Correct. Swift 6.0 refers to the next release after 5.10, not the language mode. Both the Swift 5 and Swift 6 language modes will be supported in Swift 6.0. Upcoming feature flags allow piecewise migration of code between language modes.


Thank you for clarifying @xwu.