[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

13 Likes

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
3 Likes

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 !

2 Likes