> On 19 Aug 2017, at 07:30, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Aug 18, 2017, at 12:35 PM, Chris Lattner <clatt...@nondot.org >> <mailto:clatt...@nondot.org>> wrote: >> >>> (Also, I notice that a fire-and-forget message can be thought of as an >>> `async` method returning `Never`, even though the computation *does* >>> terminate eventually. I'm not sure how to handle that, though) >> >> Yeah, I think that actor methods deserve a bit of magic: >> >> - Their bodies should be implicitly async, so they can call async methods >> without blocking their current queue or have to use beginAsync. >> - However, if they are void “fire and forget” messages, I think the caller >> side should *not* have to use await on them, since enqueuing the message >> will not block. > > I think we need to be a little careful here—the mere fact that a message > returns `Void` doesn't mean the caller shouldn't wait until it's done to > continue. For instance: > > listActor.delete(at: index) // Void, so it > doesn't wait > let count = await listActor.getCount() // But we want the count > *after* the deletion!
In fact this will just work. Because both messages happen on the actor's internal serial queue, the "get count" message will only happen after the deletion. Therefore the "delete" message can return immediately to the caller (you just need the dispatch call on the queue to be made). Thomas
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
