Sorry for the shameless bump :-/ but I’d love to get some answers so I can better understand the proposal and participate in the discussions.
> On 21 Aug 2017, at 07:58, David Hart via swift-evolution > <[email protected]> wrote: > > Hello, > > Thanks for the great work on the async/await proposal! After reading it, I > have a few questions and comments about it, so I’m creating this thread to > concentrate on that topic (instead of Actors). > > Generators > > The proposal mentions in Problem 6 of the Motivation how generators can help > write sequences: > > In contrast, languages that have generators allow you to write something more > close to this: > > func getSequence() -> AnySequence<Int> { > let seq = sequence { > for i in 1...10 { > yield(i*i) > } > } > return AnySequence(seq) > } > > This feels very similar to me from C# where the yield keyword is used to > support the generator feature. But I fail to see how the coroutines as > described in this proposal resolve this problem. Can someone explain? > > beginAsync > > The documentation of the beginAsync and suspendAsync functions state: > > // NB: Names subject to bikeshedding. These are low-level primitives that most > // users should not need to interact with directly, so namespacing them > // and/or giving them verbose names unlikely to collide or pollute code > // completion (and possibly not even exposing them outside the stdlib to begin > // with) would be a good idea. > > But I don’t understand how they can be kept private to the standard library > when they are used for the important pattern of spawning off an async > operation from a non-async function: > > Despite these problems, it is essential that the model encompasses this > pattern, because it is a practical necessity in Cocoa development. With this > proposal, it would look like this: > > @IBAction func buttonDidClick(sender:AnyObject) { > // 1 > beginAsync { > // 2 > let image = await processImage() > imageView.image = image > } > // 3 > Futures > > When discussing futures, the proposal states: > > The exact design for a future type deserves its own proposal, but a proof of > concept could look like this: > > Does that sentence imply that the Core Team would welcome a Future > implementation into the Standard Library? > > async as a subtype of throws instead of orthogonal to it > > I’ve been thinking a lot about this since the proposal came out and I see a > few serious disadvantages at making async a subtype of throws which might > benefit from being discussed or/and mentioned in the proposal. > > 1. We loose the automatic documentation try provides for signaling failable > functions: > > let image = await downloadImage() > let processedImage = await processImage(image) > await present(MyViewController(image: image)) > > In my example, downloadImage can fail because of network conditions, > processImage can not fail, and present is the UIKit function which presents > view controllers and it can’t fail either. But that’s not obvious from > reading the code. We’ve lost information. > > 2. Supporting try? and try! adds a lot of confusion: > > As was mentioned by Karim Nassar is another post, if await infers try, then > there seems to be no good solution for supporting try? and try!: > > Using await? and await! seems slightly conter-intuitive because we are > further mixing the concepts of coroutines/asynchronous operations with error > handling. > Adding try? and try! (like suggested Chris Lattner) feels like it makes point > (1) by having both explicit try?/! and implicit try through await. > > 3. Philosophical discussion > > If async calls don’t return futures because coroutines are a generally useful > language features beyond the domain of async/await, doesn’t making async > imply throws also muddy the concept of coroutines where failable coroutine > operations don’t make much sense? > > David. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
