# \[Pitch #3\] Actors **URL:** \ **Category:** Pitches\ **Created:** [February 5, 2021, 5:26am UTC](https://forums.swift.org/t/pitch-3-actors/44470 "2021-02-05T05:26:35Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Chris\_Lattner3](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/chris_lattner3/32/348_2.png) [@Chris\_Lattner3](https://forums.swift.org/u/Chris_Lattner3)\ **Post date:** [February 7, 2021, 7:23pm UTC](https://forums.swift.org/t/pitch-3-actors/44470/2 "2021-02-07T19:23:42Z")
Wow, this is huge progress. All of the changes are great! I have some further suggestions on how to improve the type system modeling of actors, which I [posted in this thread](https://forums.swift.org/t/exploration-type-system-considerations-for-actor-proposal/44540). Here are some comments from a read through of draft #3, which does not take into consideration that direction: * * * Minor typos: - "Implementation note: At an implementation level, the messages are partial tasks (described by the [Structured Concurrency] proposal)". -\> it seems like Structured Concurrency should be a link out. - Broken punctuation: "However, the [Alternatives Considered](#alternatives-considered] section". * * * I don't understand this description in the [closures section](https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md#closures) of the proposal: > [@](#): > > The specific rule determining whether a closure within an actor-isolated function is itself actor-isolated checks two properties: > > - If the closure is `@concurrent` or is nested within a `@concurrent` closure or local function, it is non-isolated, or > - If the closure is `@escaping` or is nested within an `@escaping` closure or a local function, it is non-isolated. The first bullet is always true, and I think you describe this earlier in the closure section. I think it is enough to say that `@concurrent` functions are never actor isolated. I don't really understand the second bullet though. It would help my understanding to be more specific about what is tied to the callee declaration, the function type the closure is inferred to, and the closure itself. How much of this is clang importer rules (e.g. implicitly importing completion handlers as `@concurrent`) vs rules for working with other random Swift 5 code? * * * I think this is just a writing thing, but in: > [@](#): > > #### inout parameters > > Actor-isolated stored properties can be passed into synchronous functions via `inout` parameters, but it is ill-formed to pass them to asynchronous functions via `inout` parameters. It would be good to add some rationale here. There is nothing memory unsafe (AFAIK) about this, it is just likely to trip up memory exclusivity checks and is an unnecessary booby trap to allow this. If this is required for correctness, then the restriction would have to be consistently applied to local variables as well as stored properties, since they are actor isolated state as well. I think that this is actually ok though because you get diference instances for these things for each stack frame, which makes them ok in practice. It would be good to capture some of this in the writing. * * * You explained the interaction between actors and ConcurrentValue really nicely in the Cross-actor references and `ConcurrentValue` types section! * * * In detailed design, "An actor may only inherit from another actor. " --\> I thought inheritance from NSObject was allowed? * * * It's not clear to me how `nonisolated(unsafe)` works: it looks like it can be applied to stored properties, which means that the property can be accessed from nonisolated methods. However, can it also be applied to methods as well? Are `nonisolated(unsafe)` properties only accessible from `nonisolated(unsafe)` members? Does unsafety propagate out or no? Reading later it looks like methods can be declared as `nonisolated(unsafe)` which allows them to do things to arbitrary isolated state. This seems overly dangerous to me, I think it would be better to require all the data members to be "opted into" unsafety, rather than having extensions be able to throw arbitrary unsafe logic onto actors. I'm not super excited about the whole `nonisolated` and `nonisolated(unsafe)` thing in general, if it remains, then I think it is important to get the safety story right on the `(unsafe)` version otherwise it can rapidly undermine safety goals of the entire model. * * * In the isolation checking section, the term "executable code" is a bit confusing to me (this isn't a .exe file). Is there a better term that can be used here? * * * The [Protocol Conformance](https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md#protocol-conformance) section has an offhand mention that protocol requirements can be marked nonisolated. If this is intended, then it would be good to explain the full model here. What do they mean with structs and classes that conform to the protocol, what are the subtyping rules, what does "nonisolated(unsafe)" mean on a requirement, etc. * * * In [Partial Applications](https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md#partial-applications) it would be good to spell out the type of `self.synchronous` explicitly, e.g. something like this: ```swift let fp1 : () -> () = self.synchronous // seems ok let fp2 : @concurrent () -> () = self.synchronous // invalid conversion ``` It would also be useful to expand out those two sentences at the end of this subsection into examples, because I don't understand exactly what you mean. * * * I'm very happy see the discussion of non-reentrancy included in the proposal, and I'm also very very happy to see it is in the future work section. Overall, really great job on this! -Chris --- _[View the full topic](https://forums.swift.org/t/pitch-3-actors/44470)._