[Pitch #2] Actors

[Douglas_Gregor]

@michelf

The pitch has this to say about await :

The potential for interleaved execution at suspension points is the primary reason for the requirement that every suspension point be marked by await in the source code, even though await itself has no semantic effect.

It seems to me that within a @reentrant(never) context this raison d'être of the await keyword is no more. Instead it signals a potential deadlock happening if you're not careful.

I don't agree. The await signals a potential suspension point: your code may be suspended, and any kind of global state (unprotected globals anywhere, clocks/timers, etc.) might change out from under you before you resume. The "reentrancy" discussion is about whether your actor state might also change out from under you before you resume.

@michelf

Does 3 include type nesting?

@reentrant(never)
actor X {
    actor Y {
       func something() {
           // is this reentrant or not?
       } 
    }
}

It's reentrant. I've clarified the specification and added an example.

@xwu

• Under "Existing practice," the first sentence is unfinished ("There are a number of existing actor implementations that have" is the entire sentence), and in the sentence beginning "Note that Orleans" the text misspells the word "add[s]" as "ad."
• The internal link in the table of contents to the newly inserted section "Proposal: Default reentrant actors[...]" does not work; it also seems odd to have a specific subsection in a proposal titled "Proposal" and the section heading works without that word.

Fixed, thanks!

@xwu

Under "Task-chain reentrancy," the discussion of the async example (the second example in that section) says that "Under the current proposal, this code will deadlock," but under the current proposal, actors are reentrant by default, and I thought the point was that this design decision all but eliminates deadlocks? Either the example should use @reentrant(never) attributes or it should explain how a deadlock is possible despite using reentrant actors.

I've switched it to use @reentrant(never) and dropped a stale reference to a since-removed example, thanks!

@xwu

The @reentrant and @reentrant(never) annotations are said to be supported not just for actors, but actor methods and extensions: there are no examples of the latter two uses. I imagine (it seems to be the only logical design) that a @reentrant(never) extension defaults all the methods it contains to non-reentrancy, which can then be overridden on specific methods by @reentrant to restore the original default. Can the proposal specifically show some examples to describe this behavior (or, alternatively, explain and justify what the intended behavior is if not that)?

As noted above, I've added an example and clarified the wording a bit.

@xwu

The section discussing actor inheritance summarizes the arguments for and against inheritance well. It states in concluding that "actor inheritance has use cases just like class inheritance does": this would be strengthened by providing or describing one such use case that you have in mind--or is that statement specifically referring to the first bullet point about porting existing class hierarchies?

I've added a simple example and reworded this a bit.

@xwu

Further, like those keywords for class methods, @actorIndependent can only be used on member declarations in actors or their extensions [edit: or on an actor or extension itself].

Ah, I see how you came to this conclusion, and it is somewhat of a side effect of us splitting global actors out of the proposal. With global actors, any declaration anywhere can be actor-isolated with the appropriate annotation. For example,

@MainActor var dataOnlyAvailableOnTheMainActor: String

@MainActor
extension MyViewController {
  func f() { ... }                                    // actor-isolated to the global actor MainActor
  @actorIndependent func g() { ... }  // actor-independent
}

On re-reading, I noticed that a bit of the discussion on @actorIndependent describes rules that are too general and don't make sense without also considering global actors. At a minimum, we need to get a pitch out there for global actors. I don't have a strong opinion on whether we should narrow the definition of @actorIndependent in this proposal down to the definition that makes sense in this proposal, then widen the definition again in global actors... but it seems like that will make the proposals harder to understand.

@xwu

Taking all of this into account, I would suggest consideration of using the contextual keyword nonisolated (and, of course, nonisolated(unsafe) as the corresponding unsafe feature) instead of @actorIndependent . I think nonisolated placed in front of func (or subscript or var ) inside or on an actor or its extension adequately describes the feature (without having to clarify further that it's not actor -isolated), particularly as it'd be a contextual keyword which manifestly is not supported anywhere else but in the context of such a declaration. And visually, this spelling elevates isolation and non-isolation to be more of a co-equal to actor itself, which after all is the reality ("An actor is a form of class that protects access to its mutable state.... This is enforced statically by...a set of limitations...collectively called actor isolation").

This is an interesting point. Actor isolation is certainly an important part of the declaration, with far more semantic impact than one would normally expect from an attribute. I like this suggestion. The only wrinkle I see is the use of @actorIndependent on closures, which isn't quite as amenable to contextual keywords. That said, we have the contextual keyword async in closures already, so we can probably handle this.

@xwu

What are the protocol conformance rules, class inheritance rules, and ABI stability rules for "actor-independency/non-isolation"?

Hmm, the rules are spelled out for overrides and conformance, but I suppose we could use more examples here.

Actor isolation isn't part of the ABI, so it's not ABI-breaking to change actor isolation... but it's certainly source-breaking and could lead to unfortunate runtime effects if (say) your client was compiled when your function was actor-independent and now it is actor-isolated.

@xwu

The proposal writes that @actorIndependent can be "used on a class." Do the authors mean "used on an actor "?

Ah, we meant "on a type", as in my example above.

@xwu

And given this feature (which is not illustrated by examples), do we then need an @actorDependent or @actorIsolated attribute to override the default for members declared in such actors (which attribute, if there is favorable reaction to the above design suggestion, would naturally be spelled as the contextual keyword isolated )

Yes, it's reasonable to want to specifically state that something is intended to be isolated. Closures could probably benefit from this as well. (Again, I get slightly worried about the parsing of something like { isolated in ... }, because changing that meaning would be source breaking)

Thank you!

Doug