[swift-evolution] [Concurrency] async/await + actors

Karim Nassar karim at karimnassar.com
Sat Aug 19 20:50:24 CDT 2017


> On Aug 19, 2017, at 7:17 PM, Chris Lattner <clattner at nondot.org> wrote:
> 
> 
>> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> This looks fantastic. Can’t wait (heh) for async/await to land, and the Actors pattern looks really compelling.
>> 
>> One thought that occurred to me reading through the section of the "async/await" proposal on whether async implies throws:
>> 
>> If ‘async' implies ‘throws' and therefore ‘await' implies ‘try’, if we want to suppress the catch block with ?/!, does that mean we do it on the ‘await’ ? 
>> 
>> guard let foo = await? getAFoo() else {  …  }
> 
> Interesting question, I’d lean towards “no, we don’t want await? and await!”.  My sense is that the try? and try! forms are only occasionally used, and await? implies heavily that the optional behavior has something to do with the async, not with the try.  I think it would be ok to have to write “try? await foo()” in the case that you’d want the thrown error to turn into an optional.  That would be nice and explicit.
> 
> -Chris
> 


I’d be curious to see numbers on the prevalence of try?/! across various kinds of codebases (i.e.: library code, app code, CLI utils, etc). I don’t use try? all that much, but I have used it. I also have found (IMHO) legitimate uses for try! in my unit tests where I want the test logic to be brittle with respect to expected conditions surrounding the test—to fail immediately if those conditions are not as I intend them to be.

If we can write "try? await foo()” (which I think is the right way to position this), will we be able to also write "try await foo()” ?  I’d hope that the latter wouldn’t be prohibited… as I think it would just make the former less discoverable. If I’m learning Swift and I see “try? await” on one line, and nearby just “await” it’s easier to assume that the first can produce an error and the second can’t, no?

If I’m honest, I *think* I’d rather we'd always have to be explicit about both try and await… yes it’s more to type, but it’s also a lot clearer about what exactly is happening. And if I always use "do try catch” together it forms a consistent pattern that’s easier to read and easier to learn. If sometimes it’s “do try catch” and sometimes "do await catch” and sometimes just “await" it seems to me we’ve lost some clarity and it’s harder for me to compose my understanding of the rules.

On the other hand, I can’t say I’ve given this a lot of deep thought either :)

—Karim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170819/f9c45a00/attachment.html>


More information about the swift-evolution mailing list