> On Nov 11, 2017, at 6:24 AM, Yuta Koshizawa <ko...@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
