[Actors] Revisiting "nonisolated let" with more implementation, usage, and teaching experience

[Douglas_Gregor]

@hooman

To clarify how I see it, let's have a brief look at what we referred to as distributed actor and quickly put aside as being out of scope. Distributed actor is a special case of an indirect actor . An indirect actor is an actor where you don't have its true reference (address). What you have is a handle to it (something like a witness or proxy).

So, we have been thinking about distributed actors and have a pretty solid idea of a workable model (with a pull request that implements them). I'll lean on that for my answers.

@hooman

Note that if the actor has immutable state, it can always be safely cached in the handle (which is a client-side entity) and be available for synchronous local access by the client without having to await anything.

It can be part of the handle, yes. However, in the distributed case, that might not be desirable, because creating a remote proxy for an actor then requires ping-ponging with the machine that has the real actor, so you can replicate the extra information.

@hooman

Now consider this question: Can a truly immutable state of an actor be anything other than part of its identity ?

Whatever state makes up the identity has to be immutable and replicated, yes. In an indirect or distributed actor case, it's something more than the address of the local object. In the pull request I referenced earlier, identity is the (network) address of the actor + the transport used to talk to it.

@hooman

I believe we need to come up with a way to make such identifying properties of actors (and classes) explicit and part of the API contract. This is a a higher-level concept and beyond nonisolated . Actually, I think marking them nonisolated can be conceptually misleading.

I don't understand this last bit about nonisolated being misleading. If something is part of the identity, you're going to need to be able to access it synchronously (hence, nonisolated) and for the distributed case, you also need it to be replicated so it's available on a remote proxy for the actor.

@hooman

Let me know if you are interested in continuing this discussion, maybe on another thread.

We're getting a bit far afield of nonisolated let, so it's probably best to go to another thread to dig further into distributed (or indirect) actors. We were planning on starting a discussion of distributed actors in a couple of weeks, once more of the non-distributed actors dust settles.

@Zhu_Shengqi

The issue raised here is very critical, but I suggest we first have SE-0313 (SE-0313: Improved control over actor isolation) finalized and accepted, then we can look back at how to solve the synchronous accessing of nonisolated let issue.

The main reason is that currently we have two approaches towards actor isolation:

• Using nonisolated let as value-directed way (which is described in the main body of SE-0313).
• Using @sync MyActor and @async MyActor as a type-directed way (which is mentioned in the alternatives considered section of SE-0313, see Exploration: Type System Considerations for Actor Proposal ).

While I have replied in SE-0313 that we should discuss more about the pros and cons of these two approaches, I find it quite easy to solve the problem raised in this proposal with the type-directed way ( @sync MyActor and @async MyActor ):

Hmm. Whether isolated is handled as a value-directed notion or a type-directed one should be orthogonal to nonisolated. Either way, a nonisolated method in an actor will alter some aspect of its self parameter, making it either non-isolated (in the value-directed design) or making it @async (in the type-directed design).

@Zhu_Shengqi

This is the free function that mentioned in this proposal

@Douglas_Gregor

> func displayAccount(account: BankAccount) {
  print("Account #\(account.accountNumber) owned by \(account.owners.joined(separator: ", "))")
}
> ```

Which is equivalent to the following definition using type-directed way:

func displayAccount(account: @sync BankAccount) {
 // Same synchronous accessing to BackAccount actors
}

So with the type-directed approach, no matter how we change between the let and var for property declarations, we can always access these from an actor, as long as it is a @sync BackAccount .

Your description of the semantics of the type-directed approach is correct. However, your second displayAccount is not equivalent to the example I used. The type-directed equivalent to the example I used is:

func displayAccount(account: @async BankAccount) {
 print("Account #\(account.accountNumber) owned by \(account.owners.joined(separator: ", "))")
}

The value-directed equivalent to your @sync version is this:

func displayAccount(account: isolated BankAccount) {
 // Same synchronous accessing to BackAccount actors
}

There are certainly differences between the type-directed and value-directed approaches, and we should continue to discuss those over in the review of SE-0313, but they should not have any impact on nonisolated.

@Zhu_Shengqi

Actually the issue raised in this proposal convinced me that the type-directed approach ( @sync MyActor and @async MyActor ) is a better way to solve those issues related to actor isolation, because we use the type system to handle the cases in a uniformed way instead of creating complex syntax rules just for fixing holes.

Based on the above, I think you're misunderstanding the differences between the approaches. There are definitely differences to discuss, but both approaches can model what you're discussing quite directly.

@pyrtsa

Was it ever considered to default all actor members to nonisolated, requiring an explicit isolated to all actor stored var properties and isolated functions? I couldn't quickly find it mentioned in the actors proposal at least.

We haven't seriously considered it, no. Outside of nonisolated let, use of nonisolated in actors is actually quite rare. That's part of the reason I'm making this correct proposal, because (if you put nonisolated let aside) you can make great use of actors without having to learn about nonisolated for quite a while. If we switch the polarity like you mention, there will be a lot of isolated and relatively few things in an actor that aren't labeled as isolated.

Doug