Thanks a lot for this piece: it was a great read, that could serve as primer to most discussions about async programming in general, also thanks to the various links and references.
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 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. - 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. - 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. Thanks Elviro > Il giorno 18 ago 2017, alle ore 00:24, Chris Lattner via swift-evolution > <swift-evolution@swift.org> ha scritto: > > Hi all, > > As Ted mentioned in his email, it is great to finally kick off discussions > for what concurrency should look like in Swift. This will surely be an epic > multi-year journey, but it is more important to find the right design than to > get there fast. > > I’ve been advocating for a specific model involving async/await and actors > for many years now. Handwaving only goes so far, so some folks asked me to > write them down to make the discussion more helpful and concrete. While I > hope these ideas help push the discussion on concurrency forward, this isn’t > in any way meant to cut off other directions: in fact I hope it helps give > proponents of other designs a model to follow: a discussion giving extensive > rationale, combined with the long term story arc to show that the features > fit together. > > Anyway, here is the document, I hope it is useful, and I’d love to hear > comments and suggestions for improvement: > https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 > > -Chris > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
