[swift-evolution] async void

[Adam Kemp]

> On Nov 11, 2017, at 6:24 AM, Yuta Koshizawa <koher at koherent.org> wrote:
> 
> If you replace `async` with `throws`, you can get answers.
> 
> 
>> Can you declare an async closure variable?
> 
> Yes. Like `let throwingClosure:() throws -> Void = { ... }`.
> 
> 
>> Can a non-async closure be passed to a function expecting a async closure?
> 
> Yes. Like we can pass `() -> Void` to a function expecting a throwing
> closure `() throws -> Void`.
> 
> It is possible because `(Foo) throws -> Bar` is a supertype of `(Foo)
> -> Bar`. `(Foo) async -> Bar` is a supertype of `(Foo) -> Bar` in the
> same way.
> 
> To treat an async function as a sync function is legal. It is similar
> to make a `Promise` by `Promise(value)` which is completed
> immediately.
> 
> 
>> Can an async closure be passed to a function expecting a non-async closure?
> 
> No. `() -> Void` is a subtype of `() async -> Void`. It is same as
> passing `() throws -> Void` to a function expecting `() -> Void` is
> not allowed.

But why not? Just asserting that it must work the same as throws is not a convincing argument. You have to justify why it must work that way. I think there is good reason to allow it, which I have described. What reason is there to disallow it?

>> It’s weird to me that we would allow you to have async void closures but not async void functions
> 
> I am not sure what you mean. "async void closures" and "async void
> functions" have a same type. Following two are almost same.
> 
> ```
> func foo() async -> Void { ... }
> let foo: () async -> Void = { ... }
> ```

What started this thread is my suggestion that you should be able to write an async void function. The current proposal doesn’t allow that. That’s why you have to use beginAsync.

I don’t think that makes sense. It sounds like you also think that would be strange, hence your assumption that you could.