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

[Chris Lattner]

On Aug 17, 2017, at 7:39 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> This is fantastic!  Thanks for taking the time to write down your thoughts.  It’s exciting to get a glimpse at the (possible) road ahead.

Happy to.

> In the manifesto you talk about restrictions on passing functions across an actor message.  You didn’t discuss pure functions, presumably because Swift doesn’t have them yet.  I imagine that if (hopefully when) Swift has compiler support for verifying pure functions these would also be safe to pass across an actor message.  Is that correct?

Correct.  The proposal is specifically/intentionally designed to be light on type system additions, but there are many that could make it better in various ways.  The logic for this approach is that I expect *a lot* of people will be writing mostly straight-forward concurrent code, and that goal is harmed by presenting significant type system hurdles for them to jump over, because that implies a higher learning curve.

This is why the proposal doesn’t focus on a provably memory safe system: If someone slaps “ValueSemantical” on a type that doesn’t obey, they will break the invariants of the system.  There are lots of ways to solve that problem (e.g. the capabilities system in Pony) but it introduces a steep learning curve.

I haven’t thought a lot about practically getting pure functions into Swift, because it wasn’t clear what problems it would solve (which couldn’t be solved another way).  You’re right though that this could be an interesting motivator. 

> The async / await proposal looks very nice.  One minor syntax question - did you consider `async func` instead of placing `async` in the same syntactic location as `throws`?  I can see arguments for both locations and am curious if you and Joe had any discussion about this.

I don’t think that Joe and I discussed that option.  We discussed several other designs (including a more C# like model where async functions implicitly return Future), but he convinced me that it is better to focus language support on the coroutine transformation (leaving futures and other APIs to the library), then you pretty quickly want async to work the same way as throws (including marking etc).  Once it works the same way, it follows that the syntax should be similar - particularly if async ends up implying throws.

That said, if you have a strong argument for why this is perhaps the wrong choice, lets talk about it!

-Chris