Stumped by another odd concurrency error

Using Swift
1

for simplicity’s sake, i had an actor like this:

actor A {
    init() {}
}

it has a method g, defined as such. it compiles! i duplicated g, creating a function f, which also compiles.

extension A {
    func f(_ x: sending some Codable, _ configure: sending (inout Int) -> ()) {
    }
    func g(_ x: sending some Codable, _ configure: sending (inout Int) -> ()) {
    }
}

now i declare a protocol P, which has a requirement designed to fit f:

public protocol P: AnyObject, Sendable {
    func f(_ x: sending some Codable, _ configure: sending (inout Int) -> ()) async
}
extension A: P {}

now i have a bunch of errors

Non-Sendable parameter type 'some Codable' cannot be sent from caller of protocol requirement 'f' into actor-isolated implementationSourceKit
Trading.swift(226, 25): Consider making generic parameter 'some Codable' conform to the 'Sendable' protocol
Non-Sendable parameter type '(inout Int) -> ()' cannot be sent from caller of protocol requirement 'f' into actor-isolated implementationSourceKit
Trading.swift(226, 10): A function type must be marked '@Sendable' to conform to 'Sendable'

i’ve been doing Swift Concurrency since 2021, and i feel like i understand less than when i began…

2

i believe this was a bug that was fixed by this PR, which ships in 6.3. it appears to be fixed on the dev snapshots and main: Compiler Explorer.

3 Likes
3

I probably find a bug when experimenting with your code. I filed #86029. The symptom: if I remove sending keyword from both protocol requirement and actor method signature, the code fails to compile.

EDIT: Or am I misunderstanding something? I’ve just realized that I don’t understand why the bug you linked existed in the first place. IMO whether a value’s method’s parameter is Sendable doesn’t affect that value’s sendability.

EDIT2: I thought of a possible reason. The method in the protocol is async, which means the parameter is transferred across isolation domain. The only valid scenario is the parameter is either Sendable or in disconnected region (that is,sending). However, if so, shouldn’t the protocol fail to compile in the first place when I remove sending from its method requirement’s signature? In addition, this can’t explain 1) why removing protocol P’s Sendable inheritance made the code compile, and 2) why class doesn’t have this failure.

I still think it should be fine for callee to not specifying sending even though it’s required for valid scenario, because it is caller that should guarantee it.