{"id":31914,"date":"2021-03-18T20:09:23","date_gmt":"2021-03-19T00:09:23","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=31914"},"modified":"2022-05-05T13:48:04","modified_gmt":"2022-05-05T17:48:04","slug":"swift-proposal-actors","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/03\/18\/swift-proposal-actors\/","title":{"rendered":"Swift Proposal: Actors"},"content":{"rendered":"

SE-0306<\/a> (forum<\/a>, Hacker News<\/a>):<\/p>\n

Actors allow you as a programmer to declare that a bag of state is held within a concurrency domain and then define multiple operations that act upon it. Each actor protects its own data through data isolation<\/em>, ensuring that only a single thread will access that data at a given time, even when many clients are concurrently making requests of the actor. As part of the Swift Concurrency Model, actors provide the same race and memory safety properties as structured concurrency, but provide the familiar abstraction and reuse features that other explicitly declared types in Swift enjoy.<\/p>

[…]<\/p>

As a special exception to the rule that an actor can only inherit from another actor, an actor can inherit from NSObject<\/code>. This allows actors to themselves be declared @objc<\/code>, and implicitly provides conformance to NSObjectProtocol<\/code>[…]<\/p>

[…]<\/p>

Like classes, actors as proposed allow inheritance. However, actors and classes cannot be co-mingled in an inheritance hierarchy, so there are essentially two different kinds of type hierarchies. It has been proposed<\/a> that actors should not permit inheritance at all, because doing so would simplify actors: features such as method overriding, initializer inheritance, required and convenience initializers, and inheritance of protocol conformances would not need to be specified, and users would not need to consider them. The discussion thread<\/a> on the proposal to eliminate inheritance provides several reasons to keep actor inheritance[…]<\/p><\/blockquote>\n\n

Previously:<\/p>\n