SE-0313: Improved control over actor isolation

[Douglas_Gregor]

@Chris_Lattner3

Isn't it concerning that it isn't "in the actor code"? This is making the author of the actor anticipate suspensions/reentrancy at await sites as usual, but also makes them look for "closures that take an isolated self parameter and are async". This complicates / defeats the simplicity of the 'await marking' approach, and undermines a significant amount of local reasoning that would otherwise exist.

The closure is "in the actor code". It's the unnamed-function equivalent to defining a method on the actor, no more and no less.

@Chris_Lattner3

Why is this a better model than not having the magic? I haven't heard rationale for why we'd want to introduce this -- it isn't essential to the model or to expressivity. It is just stated as included behavior without much rationale.

The primary motivation for isolated parameters in this proposal is to allow us to generalize from a method on an actor:

actor A {
  var counter = 0

  func inc() { counter += 1 }
}

to being able to write a free function with the same capabilities:

func inc(a: isolated A) {
  a.counter += 1
}

This feature we're discussing lets you generalize from a method on an actor to a closure that's defined within the actor.

@Chris_Lattner3

I'm very sensitive to making the actor reentrancy model more complicated given that this is one of the boldest design stakes taken by the actor design.

It's independent of the actor reentrancy model. [isolated self] on a closure is no less explicit than calling an actor method from that closure.

@Chris_Lattner3

Here's what I'm trying to ensure that we reject correctly with an analogy for comparison:

actor MyActor {
  func takeClass(_ x : NSMutableString) {...}
  func takeIsolated(_ x : isolated MyActor) {...}

  func test(a : isolated MyActor, otherActor: MyActor, str: NSMutableString) {
     // Ok to pass isolated things and classes internally to an actor.
     self.takeClass(str)   // ok
     self.takeIsolated(a) // ok

     // Not ok to pass these to other non-isolated actors.
    otherActor.takeClass(str) // error: NSMutableString isn't @Sendable
    otherActor.takeIsolated(a)  // error: cannot isolated actor references aren't @Sendable
  }
}

I'm specifically bringing up the last error there. I'm pointing out that the sendability check for cross-actor hops needs to be applied to isolated actor references like that.

The problem with the last line isn't about Sendable at all: it's about two isolated parameters in the same call being fulfilled by different actor arguments, so there is no single executor that we can jump to.

Let's step back slightly, because the statement "isolated actor references aren't Sendable" isn't a well-formed one to make. Types are Sendable or non-Sendable, values cannot be Sendable or non-Sendable because values don't conform to protocols. Types conform to protocols.

@Chris_Lattner3

@Douglas_Gregor

I've concluded that it is a mistake for this proposal to admit multiple isolated parameters at all. We should ban multiple isolated parameters.

I completely disagree. Banning this has no apparent value, undermines a future direction, and complicates the language. We discussed this quite a bit in previous rounds of the proposal. I think that this is really important for (admittedly advanced!) use cases, and I don't think that banning it has any value.

The argument for allowing multiple isolated parameters came from here:

• "Therefore, we prohibit the definition of a function with more than one isolated parameter:" --> Why? This can be narrowly useful (e.g. unsafe casts when two actor instances are known to be on the same executor) and there is no reason to ban it. Why exclude a (narrowly useful) valid case and add the compiler complexity? I don't see any safety benefit to this.

I don't believe we've seen a use case for this that doesn't require unsafe casts. We've removed several other "unsafe" features (e.g., nonisolated(unsafe)) that had stronger use cases, based on the principle that we want to start with the safe model and learn more before we add unsafe things.

The argument that it is less complex to allow multiple isolated parameters than it is to prohibit them hasn't held up, as this discussion has repeatedly shown.

Multiple isolated parameters should be removed from this proposal. They can be added back when there is a way to safely indicate that various different actor instances share the same executor. Then, they'll be worth the complexity they add.

Doug