On Aug 18, 2017, at 6:50 AM, Elviro Rocca <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
