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
