Different sending behavior between global actor and isolated parameter within a closure

[mattmassicotte]

Description

I'm trying to understand the difference between these two forms. I think they should be equivalent, but the global actor version works and the isolation param version does not.

Reproduction

class Argument {
}

class NonSendable {
    public func noArgument(closure: () -> Void) {
    }
    
    public func isolatedNoArgument(isolation: isolated (any Actor)? = #isolation, value: Argument) {
        noArgument() {
            Task {
                _ = isolation
                
                // ERROR: Sending 'value' risks causing data races
                print(value)
            }
        }
    }
    
    @MainActor
    public func globalActorArgument(value: Argument) {
        noArgument() {
            Task {
                print(value)
            }
        }
    }
}

Expected behavior

I expected both of these versions to compile with no error.

Environment

Apple Swift version 6.0-dev (LLVM 3751470251df3e4, Swift 026ffdd)
Target: arm64-apple-macosx14.0

Additional information

No response

[mattmassicotte]

I think I may have simplied this down even more.

class Argument {
}

class NonSendable {
    public func noArgument(closure: (isolated (any Actor)?) async -> Void) {
    }

    public func isolatedNoArgument(isolation: isolated (any Actor)? = #isolation, value: Argument) {
        // here, self *must* be on isolation
        noArgument() { innerIsolation in
            // closure is non-Sendable
            // so innerIsolation must be isolation

            // ERROR: sending 'value' risks causing data races
            print(value)
        }
    }
}

If I remove the isolated param from closure, this compiles fine.

[hborla]

I agree that your original examples in the issue description should behave the same. Your example in #75910 (comment) looks different, though, and I'm not convinced the compiler error in that case is a bug.

[mattmassicotte]

Ok, at the very least it is quite different. I've opened a seperate bug for that one:

#76038

[gottesmm]

This is fixed in 0ece31e

[mattmassicotte]

Confirmed - thank you so much!