4 ms·

I read earlier versions of the Actor proposal, and maybe I misunderstood, but it seemed like the design was oriented towards UIKit. That’s what made it interest

I read earlier versions of the Actor proposal, and maybe I misunderstood, but it seemed like the design was oriented towards UIKit. That’s what made it interesting for me. Has that changed? Specifically, actors would alleviate the the mental overhead of constant dispatch queue management littering iOS codebases. Certain UIKit classes would gain @UIActor and suddenly you get a compiler error if you try to modify a view from a background thread. I can’t seem to find any references to that in the current proposal. Regardless, I’m excited for actors to land in the next release. I’m just concerned adoption will be similar to Swift 3’s do/try/catch syntax, which didn’t take off until UIKit converted all fallible synchronous methods from `(Data?, Error?)` to `throws`.

vrtcn 5y ago
As far as I know, the new concurrency features can be adopted gradually which would make it very simple for developers to transition from the current completionHandler-based model to the new async/await-based model. Every Obj-C UIKit method with such a completionHandler parameter would from now on be available in two ways from Swift: 1. as usual, with completionHandler 2. new, without completionHandler, marked as ‚async‘ and returning the input types of the completionHandler
Grustaf 5y ago
No, interacting with UIKit is just one example usage, though important enough to warrant special constructs like that. The people that seem most excited to me are those that work with server side Swift.
- oscargrouch 5y ago
  From the server side perspective, this Actor implementation is cheap(to develop), safe and more developer friendly. But i don't know if it will be the most performant implementation as it will depends of how much state copy between threads its involved (as this is the common bottleneck in performance on a multi-threaded implementation). So a more classic implementation might perform a little better, but i don't know if this will also stand true in Swift as the compiler might use tricks behind the curtains to optimize things giving the people behind this also control the Swift compiler.

vrtcn 5y ago

As far as I know, the new concurrency features can be adopted gradually which would make it very simple for developers to transition from the current completionHandler-based model to the new async/await-based model. Every Obj-C UIKit method with such a completionHandler parameter would from now on be available in two ways from Swift: 1. as usual, with completionHandler 2. new, without completionHandler, marked as ‚async‘ and returning the input types of the completionHandler

Grustaf 5y ago

No, interacting with UIKit is just one example usage, though important enough to warrant special constructs like that. The people that seem most excited to me are those that work with server side Swift.

oscargrouch 5y ago
From the server side perspective, this Actor implementation is cheap(to develop), safe and more developer friendly. But i don't know if it will be the most performant implementation as it will depends of how much state copy between threads its involved (as this is the common bottleneck in performance on a multi-threaded implementation). So a more classic implementation might perform a little better, but i don't know if this will also stand true in Swift as the compiler might use tricks behind the curtains to optimize things giving the people behind this also control the Swift compiler.