[Pitch #2] Actors

[Douglas_Gregor]

@Chris_Lattner3

Right. The design in the @concurrent closure doc says that @concurrent closures are guaranteed to be actor isolated (i.e., they could be from a different concurrency domain) and non- @concurrent closures are guaranteed to be usable within the same actor. This should work completely safely by composition of the rules described there.

It doesn't work completely safely because of escaping closures.

@Chris_Lattner3

@Douglas_Gregor

This is why @ktoso and I keep bringing up the "escaping implies not actor-isolated" approach in different forms. Perhaps we can tackle it directly by saying that escaping closure is always actor-independent.

Yes, I agree that this is a serious issue with detailed tradeoffs. I think we have to decide how important this is and how problematic it is to accept. My belief (which is not based on data) is that all such code will be correct in the new model or is already buggy. This is by virtue of the fact that there has to be explicit synchronization in the code to make it safe in Swift 5.

My opinion is based on porting code to the new model, and escaping closures that attempt to access actor state came up fairly often where the compiler caught me. Some of it is porting detritus, e.g., a myQueue.async { ... } in a class that's getting ported to an actor. The more persistent issues come up when setting a callback somewhere that calls back into the actor, e.g., wiring up a subscriber into a reactive streams library, setting up an event handler in a UI or in reaction to some other external event. All of those common patterns will continue to use @escaping, and relying on folks to go back and ensure that those places gain a @concurrent to prevent data races on actors undercuts the whole model. I consider this problem to be an order of magnitude worse than the one solved by ConcurrentValue.

@Chris_Lattner3

The only point I was trying to make is that the writing will be completely different if/when we take some form of the @concurrent attribute for closures. That design subsumes the whole escaping discussion for example (regardless of which way the design is resolved towards).

I doubt it will be that different, so long as it's not trying to solve both problems at once and can reference a definition of a concurrent closure/local function elsewhere, the rule is: if the place where self is captured is concurrent or escaping, it's independent of the actor.

@Chris_Lattner3

In any case, it is very possible to make @concurrent be a tower that implies @escaping

As I've noted repeatedly, this is not what I'm proposing.

@Chris_Lattner3

As I tried to show above, there are concurrent closures that are non-escaping, and escaping closures that are non concurrent.

Yes, I know, but you're arguing against a position I haven't ever held. I described the reasons for each cell in the escaping/concurrent matrix specifically over here.... 23 days ago.

There are very interesting questions about @concurrent functions and closures to resolve that are getting drowned out by this. Fortunately, most of the implementation is straightforward, including how mutating checking ties in with the "may execute concurrently with" checks from the "Preventing Data Races" document. But these are better dealt with in the other thread.

@Chris_Lattner3

If instead you say that "the way to interface with ObjC is with the @objc attribute" then you don't pollute the namespace with all this stuff. The actor can still conform to NSObjectProtocol if they want to. Instead of the above subclass, you'd just have @objc actor Foo { ... } .

Such a design also seems more consistent with the rest of the ObjC interop: we don't require Swift classes to subclass NSObject to bridge (though that is also allowed for classes of course), we only require them to be tagged with @objc .

Right now, if you declare an @objc class, it must inherit from NSObject. That's also the only way to conform to NSObjectProtocol. And the latter brings in most of the legacy methods, so I don't know that we'll fix much by making actors different from classes in this regard.

You can declare @objc members without inheriting from NSObject, of course. I think that's what you're remembering.

Doug