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

[Chris Lattner]

On Aug 18, 2017, at 6:50 AM, Elviro Rocca <retired.hunter.djura at gmail.com> wrote:
> Here's my thoughts:
> 
> - You might have been too soft on the callback-based syntax of many Cocoa APIs: those are really bad, and in general a pain to use. Of course a import strategy for future Swift will be needed, but I wouldn't consider design constraints exclusively derived from some Cocoa APIs shortcomings, like URLSession.dataTask(withURL:completionHandler:) that I think can be safely ignored.

I don’t think the design is being constrained by Cocoa, I look at it as the right answer which conveniently dovetails almost perfectly with Cocoa - similar to when Swift 2’s error handling mechanic absorbed the NSError patterns.  In the case of error handling, the most common uses were absorbed directly, but the odd cases were not.  I expect the same to happen here if async/await is adopted.

> - I agree on the focus on async/await as compiler-level tools for defining and using coroutines, with Future<T> and stuff like that to be considered as library functions built on top of the syntax: this way async/await doesn't become mere syntactic sugar.
> 
> - I really STRONGLY disagree on conflating async and throws: they are different things, and exist for different purposes, the same way as Future<T> and Result<T> are different things and should be usable separately. The right way to handle a "failable" future is to simply use a Future<Result<T>>, and eventually define convenience functions for the "success" and "failure" cases, or event methods on Future (in this case a ResultType protocol would be needed). It's a lot better to define simpler concepts that compose in interesting ways, rather than conflating unrelated things for minor conveniences.

I understand your concern, but other communities (e.g. Rust and C#) have chosen to conflate them out of practicality.  Joe Groff has a lot to say about this, hopefully he chimes in.

> - async/await is good, but the Actor model part is simply glorious :D
> 
> - I'm so happy that adding a native idiomatic Actor model has been considered for Swift, and I like the interplay with await for making actor functions return, as well as the progressive disclosure that can be achieved with more and more restrictive keywords: it even seems to me a real step-up from existing implementations of the model.
> 
> - in general I think that one of the best (if not the best) features of Swift is the idea of progressive disclosure, and that should be preserved... and I'm a fan of "actor class" :D
> 
> - I like the "ValueSemantical" protocol idea, but eventually I would like Swift to have features to actually enforce safe patterns though the language itself, like a "pure" or "safe" keyword: I almost use no classes (excluding the UIKit ones that I'm forced to use) and mostly write pure functions, but as the language forces me to do extra work when I'm dealing with an Optional or a throwing function, and that's a good thing in my opinion and facilitates my work as a software engineer, I would love a language that warned me that I'm accessing a potentially mutable instance with reference semantics in a context that I'm mistakenly considering as pure, or that the function I'm writing is not actually pure because a non-pure function was called inside it.

Understood.  There are other interesting and potentially related opportunities that could dovetail here.  Several people have discussed adding a first class COW concept to the language to easy the implementation of COW types (here’s one proposal: https://github.com/eeckstein/swift/blob/cow-proposal/docs/proposals/CopyOnWrite.rst <https://github.com/eeckstein/swift/blob/cow-proposal/docs/proposals/CopyOnWrite.rst>).  Something like that could help.

> - I love the way the "actor" keyword for a method transforms it in an "inbox": I think the implementation you're proposing is super "Swifty" and could appear so convenient that many people could be drawn to the language just thanks to the great native concurrency model; I think that a powerful but simple and usable concurrency model is a heavy motivation for adopting a certain language in many contexts.

Awesome!

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170818/28800b13/attachment.html>