Add reference for 'nonisolated' [SE-0449] #369
Conversation
| XXX TR: Are there any declarations you can't mark nonisolated? | ||
| The SE proposal says "all type and protocol declarations". | ||
| It seems like "nonisolated actor" wouldn't make sense, for example, | ||
| but this compiles: nonisolated actor A { } |
There was a problem hiding this comment.
Filed rdar://158142168
| "on any actor" vs "on the shared thread pool"? | ||
| Or would this be clearer as explained in contrast to "isolation", | ||
| as defined in the new section in the Concurrency chapter? | ||
| --> |
There was a problem hiding this comment.
Suggestion:
Apply this modifier to a declaration to suppress any implicit
isolation that would ordinarily apply to it. For example, a
nonisolatedproperty of an actor is not isolated to
self, and anonisolatedmethod of a@MainActor
class is not isolated to the main actor.A
nonisolatedmethod or property is just like any other
function or variable that is not isolated to an actor. For
example, you can call a non-isolated synchronous method
of an actor from outside the actor without marking the call
withawait. In turn, the body of the method or property is
treated as if it were outside the actor for isolation purposes.
For example, if you call an isolated method from a non-isolated
method, you must mark the call withawait.
Maybe add an example showing this. Then I think we continue with the discussion of nonisolated types and extensions.
There was a problem hiding this comment.
Revised in b89c629.
| I'm not sure the above is correct. | ||
| Does this also apply to nonsendable variables? | ||
| Any context where you'd be overriding an inferred isolation? | ||
| --> |
There was a problem hiding this comment.
This doesn't seem right. I think this might be backwards — you've got it right below with "Sendable variables and properties".
There was a problem hiding this comment.
Thanks. This came from SE-0449:
Currently, any stored property of a non-Sendable type is implicitly treated as non-isolated.
Maybe I'm misreading the example though — it's not clear to me whether this section is talking about properties whose type is nonsendable, or properties that are on a nonsendable type. In the code example, both the property and the type it's on are nonsendable.
| class MyClass { | ||
| nonisolated var x: NonSendable = NonSendable() | ||
| } | ||
| --> |
There was a problem hiding this comment.
Suggestion:
Swift restricts non-isolated stored variables so that they can provide
data isolation without using an actor. Non-isolated global
variables, static properties, and instance properties of actors and
sendable classes must beletconstants of a sendable type.
Non-isolated instance properties of sendablestructs must
have a sendable type, but they are allowed to be mutable.If a stored variable meets the conditions for being nonisolated,
Swift will allow it to be used as if it were markednonisolated
within the module that defines it. To use it asnonisolated
outside of that module, you must mark itnonisolatedexplicitly.You can bypass these restrictions by marking a stored variable
nonisolated(unsafe). You are then responsible for ensuring
that the variable is only accessed in correctly-ordered ways.
This may be appropriate if, for example, you are protecting the
variable with a mutex and cannot use Swift'sMutextype.
Co-authored-by: John McCall <[email protected]>
Co-authored-by: John McCall <[email protected]>
Fixes: rdar://87855254
Fixes: rdar://142629242
Fixes: rdar://144571564