Skip to content

Commit e400ea7

Browse files
simanerushrjmccall
andauthored
Update proposals/NNNN-global-actor-isolated-types-usability.md
Co-authored-by: John McCall <[email protected]>
1 parent 6843710 commit e400ea7

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

proposals/NNNN-global-actor-isolated-types-usability.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ extension S: Equatable {
2929
}
3030
```
3131

32-
Because `S` is a value type and `x` has the `Sendable` type `Int`, it is never unsafe in itself to use `x` from different concurrency domains. `x` is mutable, but since `S` is a value type, any mutation of `x` is always part of a mutation of the containing `S` value, and the concurrency model will prevent data races at that level without needing any extra rules for `x`. If we do have concurrent accesses to `x` on the same `S` value, they must both be reads, and it's fine to have concurrent reads of the same value as long as it's `Sendable`. So, first off, it should be possible to declare `x` as `nonisolated` without adding `(unsafe)`.
32+
However, there is nothing unsafe about treating `x` as nonisolated. The general rule is that concurrency is safe as long as there aren't data races. The type of `x` conforms to `Sendable`, and using a value of `Sendable` type from multiple concurrent contexts shouldn't ever introduce a data race, so any data race involved with an access to `x` would have to be on memory in which `x` is stored. But `x` is part of a value type, which means any access to it is always also an access to the containing `S` value. As long as Swift is properly preventing data races on that larger access, it's always safe to access the `x` part of it. So, first off, there's no reason for Swift to require `(unsafe)` when marking `x` `nonisolated`.
3333

3434
We can do better than that, though. The only problem with treating `x` as *implicitly* `nonisolated` is source and binary stability: someone could reasonably change `x` to be a computed property in the future, and the getter and setter for that might need to be global-actor-isolated. Within the module, though, we know that hasn't happened. So Swift should treat stored properties like `x` as implicitly `nonisolated` when they're used from the same module, or when the containing type is declared `frozen`.
3535

0 commit comments

Comments
 (0)