[Pitch #2] Actors

[xAlien95 (Stefano De Carolis)]

@xwu

This applies equally to the already-accepted async in ... syntax.

Are you referring to this quote?

@Douglas_Gregor

@Chris_Lattner3

Closure expressions have a "lot" of sugar (citation needed), and I think it is important for this to work consistently with throws in closure expressions. Should we allow { async in ...} as sugar for "infer the signature, but make it async"? I'm not actually sure if that works with throws closures - I sort of hope not :-)

It works with throws , and async does exactly the same thing.

There are no mentions of this contracted syntax in the accepted SE-0296 and { throws in } never worked as I'm aware. What does work is { throw MyError } which implicitly infers a throws closure type (analogously, { await 3 } implicitly infers an async closure type and this is explicitly stated in the proposal).