[swift-evolution] [Concurrency] async/await + actors

[Chris Lattner]

On Aug 18, 2017, at 11:56 AM, David Beck <david at davidbeck.co> wrote:
> ## Conversion of imported Objective-C APIs
> 
> One issue I see with the importer is that the conventions for callbacks aren’t as strict as NSError ** methods were. For instance, URLSession completion blocks include response, data and error, all of which are optionals. The response is almost always present, even if there was an error. But there is no way to know that from the ObjC type system, and no way to represent a throwing function that also returns metadata on error in Swift.

Sure, the default would be to import these as just a bunch of optionals.  Something better could be done on a case by case basis (in overlays) though.

> 
> How should we represent dataTask(with:completion:)?

Someone else brought this up.  The most conservative thing is to leave it as a completion handler, and only transform void-returning ObjC methods.

> ## Actors
> 
> I fail to see the benefit of adding an entirely new construct for the actor model. It seems like access control, value semantics, and dispatch queues largely fill this need already, and the implimentation of an actor wouldn't be so complicated currently that it needs a compiler feature to ensure a correct implimentation.

It really comes down to whether you think elimination of shared mutable state is worth it, and if you think that having a higher level answer for concurrency is worth it.  Reasonable people can differ on this, and I expect opinions to vary, because GCD and other existing things are pretty good.  I think we can aim higher though.

-Chris