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

Co-authored-by: John McCall <[email protected]>

Author: simanerush

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

@@ -31,7 +31,7 @@ extension S: Equatable {
 
 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`.
 
-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`.
+We can do better than that, though.  It should be possible to treat a `var` stored property of a global-actor value type as *implicitly* `nonisolated` under the same conditions that a `let` property can be.  A stored property from a different module can be changed to a computed property in the future, and those future computed accessors may need to be isolated to the global actor, so allowing access across module boundaries would not be okay for source or binary compatibility.  But within the module that defines the property, we know that hasn't happened, so it's fine to use a more relaxed rule.
 
 Next, under the current concurrency rules, globally isolated functions and closures do not implicitly conform to `Sendable`. This impacts usability, because these closures cannot themselves be captured by `@Sendable` closures, which makes them unusable with `Task`: