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

[Chris Lattner]

On Aug 17, 2017, at 10:50 PM, Andre <pyunpyun at me.com> wrote:
> Part 1: Async/await
> 
>     let dataResource  = await loadWebResource("dataprofile.txt")
> 
> 
> Was there any thought about introducing the concept of a timeout when awaiting?
> 
> Something like an `await for:` optional parameter?
> Then, if used with try, it could go like…
> 
>     let dataResource  = try await for:10/*seconds*/ loadWebResource("dataprofile.txt”) catch _ as Timeout { //abort,retry cancel } 
> 
> Timeouts should probably be handled at a higher level, but its just something that jumped out to me a little, since its something I notice sometimes people neglect to take care of… :/

Something like this could definitely be built and added later: the sketch for async/await is intentionally kept as minimal as possible.  That said, this seems like it is wandering into territory that would make sense to be API, rather than first class language feature.

> Part 2: Actors
> One other thing that also jumped at me was, if we are going to have actors, and having them encapsulate/isolate state, would it also make sense to make sure that we can’t invoke state changing messages when its invalid?
> 
> As an example, if we had a ”downloader” actor that downloads multiple files, we wouldn't want to be able to send invalid messages such as `begin` when downloading has already ”begun”…. Would it then make more sense to have callable messages be determined by the publicly visible state of the actor instead?

Yes, I completely agree and know what you’re talking about here.  You’re unintentionally poking one of my other axes the grind.  :)

This desire (to have conceptual “states” that a type moves through) is something that is super common.  Files can be in “initialized” and “open” states, and that changes the valid actions that can be performed on them.  A mutex can be locked or unlocked etc.  Being able to express these invariants is highly related to pre and post conditions.

One abstraction that has been developed in the industry is the notion of typestate (https://en.wikipedia.org/wiki/Typestate_analysis <https://en.wikipedia.org/wiki/Typestate_analysis>), which underlies common abstractions in static analyzer tools like the Clang Static Analyzer.  I would love to see these ideas developed and built out at some point in time, and perhaps the next time I get a long block of time I’ll write another manifesto on those ideas ;-)

Coming back to your point, these ideas apply just as much to structs and classes as they do actors, so I think it should be a feature orthogonal to actors.

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