[Pitch #3] Actors

[Douglas_Gregor]

@Chris_Lattner3

I don't understand this description in the closures section 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?

It's not limited to the Clang importer, as existing Swift code is equally as likely to take a completion handler (or other escaping function parameter) that is then called later, concurrently with the actor.

I'm clarifying and expanding on this section somewhat.

@Chris_Lattner3

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.

Right, it's not memory-unsafe, but reentrancy of actors means that it is very, very easy to trigger new kinds of exclusivity violations. I'm adding more rationale.

@Chris_Lattner3

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?

This was a mistake: nonisolated(unsafe) should only apply only to stored properties, and should mean "don't do isolation checking." Really, I'd like to replace nonisolated(unsafe) with @concurrent(unsafe) down in the ConcurrentValue proposal, because it's a general "opt this declaration out of concurrency checking" annotation that shouldn't be specific to actors.

@Chris_Lattner3

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?

I agree that "executable code" is strange. I'll talk about this in terms of calls and references instead.

@Chris_Lattner3

The 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.

Ahh... this is somewhat tied in with global actors, which we're separating out. I'll simplify this down to eliminate the notion of actor isolation for requirements here.

@Chris_Lattner3

In Partial Applications it would be good to spell out the type of self.synchronous explicitly, e.g. something like this:

  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.

This section is a mess. I'm going to rework it a bit.

Thanks for the review!

Doug