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

[beccadax (Becca Royal-Gordon)]

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

[Nickolas_Pohilets (Nickolas Pokhylets)]

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

[hborla (Holly Borla)]

@Nickolas_Pohilets

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:

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

[KeithBauerANZ (Keith Bauer)]

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

[beccadax (Becca Royal-Gordon)]

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

5. Prohibition of marking methods @Sendable when the type they belong to is not @Sendable .

class C {
    var random: Int = 0 // random is mutable so `C` can't be checked sendable

    @Sendable func generateN() async -> Int { //error: adding @Sendable to function of non-Senable type prohibited
         random = Int.random(in: 1..<100)
         return random
    }
}

func test(x: C) { x.generateN() }

let num = C()
Task.detached {
  test(num)
}
test(num) // data-race

[angela-laar]

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

[angela-laar]

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

[James_Dempsey]

@beccadax

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!

[xwu (Xiaodi Wu)]

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.

[James_Dempsey]

Thank you for clarifying @xwu.