In converting an existing codebase (not large, but with a variety of completion-handler-based asynchronicity strategies), I ran into a couple of ergonomic issues. I don't recall these being discussed during the pitch phase of Swift concurrency, so I'm offering them as ideas for general discussion here and in related forum threads.
I ran into the following scenario:
async let results = someAsyncThrowingSequence()
…
for try await let result in results {
…
}
Sadly, that doesn't compile. What I had to write was:
for try await let result in try await results {
…
}
Ugh! It looks like the compiler treats for try await as a single, compound keyword, so it doesn't mark the entire statement as having a suspension point as try await normally would.
Could this be regarded as a compiler bug, since it's the only statement I can think of that requires multiple try await incantations?
Additionally, the following syntax:
try await for let result in results {
…
}
means something different to the compiler. Would it be safe to have the compiler interpret try await for as for try await, based on the type of the expression after the in, which would determine whether this is a synchronous or asynchronous for?