Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Returned sending value can not be passed into sending parameter in another function #78135

Open
muukii opened this issue Dec 12, 2024 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels

Comments

@muukii
Copy link

muukii commented Dec 12, 2024

Description

No response

Reproduction

 class _NonSendable {
    init() {
    }
  }

 class Class_1 {
            
    nonisolated func run_sending<T>(_ closure: () -> sending T) -> sending T {  
      let t = closure()
      return t
    }
    
    nonisolated func sub<T>(_ value: sending T) {
      print(value)
    }
    
    nonisolated func main() {
            
      let r = run_sending {
        _NonSendable()
      }
      // ❌ why is this error?
      sub(r)
            
      do {
        let r = _NonSendable()
       // this is fine
        sub(r)
      }
                      
    }
    
  }

Expected behavior

Should not the returned value as sending be able to be passed into a sending parameter in another function?

Environment

swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)
Target: arm64-apple-macosx15.0

Additional information

No response

@muukii muukii added bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels labels Dec 12, 2024
@muukii
Copy link
Author

muukii commented Dec 12, 2024

this is also related
#77199

@jamieQ
Copy link
Contributor

jamieQ commented Dec 13, 2024

this example appears to compile on a recent nightly toolchain (compiler explorer example). a potential workaround is to ensure the functions that return sending values do not implicitly take additional parameters that may affect the inferred isolation regions (e.g. the implicit self of instance methods). this can be done in this case by either making the method static or a free function, e.g.

class _NonSendable {}

private func run_sending<T>(
    _ closure: () -> sending T
) -> sending T {
    let t = closure()
    return t
}

class Class_1 {
    nonisolated func sub<T>(_ value: sending T) {
        print(value)
    }

    nonisolated func main() {
        let r = run_sending {
            _NonSendable()
        }
        sub(r)
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels
Projects
None yet
Development

No branches or pull requests

2 participants