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

Description of sending in Flow-Sensitive Isolation Analysis needs more elaboration #123

Open
bjo0 opened this issue Jul 16, 2024 · 1 comment

Comments

@bjo0
Copy link

bjo0 commented Jul 16, 2024

https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/dataracesafety#Flow-Sensitive-Isolation-Analysis

The text on it is as follows:

Region-based isolation works without any code changes. But a function’s parameters and return values can also explicitly state that they support crossing domains using this mechanism.

func populate(island: Island, with chicken: sending Chicken) async {
    await island.adopt(chicken)
}

The compiler can now provide the guarantee that at all call sites, the chicken parameter will never be subject to unsafe access. This is a relaxing of an otherwise significant constraint. Without sending, this function would only be possible to implement by requiring that Chicken first conform to Sendable.

Based on this, I don't feel like I understand how to reason about using sending. Is the compiler still going to guarantee safety, or is this a foot gun? If it still guarantees safety, how is it any different than omitting sending? Another sentence or two, or a reference to a more detailed explanation, would be helpful.

@mattmassicotte
Copy link
Collaborator

mattmassicotte commented Jul 18, 2024

Yes, I agree. There is no unsafety here. But, this example in isolation doesn't make it clear enough that without sending, this code will not compile because the compiler cannot guarantee that chicken can be transferred across domains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants