<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">From what I understand, the C# and Swift designs are different:</div><div class=""><br class=""></div><div class="">- C# async functions immediately return a task which can be enqueued to complete the work (including selecting which queue for UI cases, etc). Tasks have callback behavior attached to them.</div><div class=""><br class=""></div><div class="">- Swift async functions immediately enqueue to do work along with a callback function to be executed once work finishes. There is no first-class representation of a Future or the like, at least by default (a callback function could be promoted to a future). There is no support for selecting which queue work or the callback runs on (although your callback could immediately enqueue work on the appropriate thread, but this does increase latency in busy systems)</div><div class=""><br class=""></div><div class="">Assuming I got the above all correct there is no async Task vs async Void in swift, because a function which dispatches work to a queue without taking a callback just returns void. Those functions aren’t “async” at all, you can call them normally to dispatch work just as easily as you could call them within an async block, and they would have the same behavior. They also can’t be “awaited”, because there is no callback mechanism to tell when the work completes.</div><div class=""><br class=""></div><div class="">Thats not to say I wouldn’t prefer the Task-type design, but it isn’t how most of the legacy asynchronous code is written to work (and would have some issues with GCD, since you can’t discover your current queue in order to enqueue more work there by default)</div><div class=""><br class=""></div><div class="">// Function which asynchronously dispatches work, without triggering any callback. If it throws, the error represents a synchronous issue (e.g. bad parameters or state)</div><div class=""><br class=""></div><div class="">func doWorkBlindly();</div><div class=""><br class=""></div><div class="">// Function which asynchronously dispatches work, returning a callback without data but possibly indicating an error</div><div class="">func doWorkExceptionally() async -> Void;</div><div class=""><br class=""></div><div class="">// Function which asynchronously dispatches work ,returning data and possibly an error</div><div class="">func doValuableWork() async -> Data;</div><div class=""><br class=""></div><div class="">// works fine</div><div class="">doWorkBlindly()</div><div class="">beginAsync {</div><div class=""> // has the same behavior as above</div><div class=""> doWorkBlindly()</div><div class=""> do {</div><div class=""> // can only be called within an async block</div><div class=""> await doWorkExceptionally()</div><div class=""> let result = await doValuableWork()</div><div class=""> }</div><div class=""> catch {</div><div class=""> fatalError()</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 12, 2017, at 10:56 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Sorry, I'm just getting into this conversation late and am by no means experienced in the area, but why can't the one where you *don't* want the caller to wait for the result be spelled `async -> Never`? Theoretically, `async -> Void` means you're awaiting a result with only one possible value, but if you're not waiting at all, then there is truly no result, yes?<div class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Nov 12, 2017 at 9:27 AM, Yuta Koshizawa via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry, I had got some confusion. Please let me retry to explain.<br class="">
<br class="">
As you said, C# provides three kinds of async functions: `async Void`,<br class="">
`async Task` and `async Task<Foo>`. All of them are necessary and<br class="">
Swift should provide same functionalities.<br class="">
<br class="">
When we think about `async/await` in Swift, because we have already<br class="">
had `throws/try`, it is desired that `async/await` in Swift is<br class="">
consistent with `throws/try`. So it is better to have `async/await`<br class="">
without introducing a type like `Task` (or `Promise`).<br class="">
<br class="">
Even if we employ `async/await` without `Task`, Swift has to provides<br class="">
functionalities to implement "three kinds of async functions" in C#.<br class="">
However if `async -> Void` in Swift works similarly to `async Void` in<br class="">
C#, how can we express ones like `async Task` in C#? I think there are<br class="">
two possibilities:<br class="">
<br class="">
1. Calling `async -> Void` functions without `await` in Swift works<br class="">
like `async Void` in C# and calling them *with* `await` works like<br class="">
`async Task` in C#.<br class="">
2. Calling `async -> Void` functions without `await` in Swift works<br class="">
like `async Void` in C# and never support something like `async Task`<br class="">
in C#.<br class="">
<br class="">
I think 2 is impermissible. For example, handling completion events of<br class="">
asynchronous operations without result values needs something like<br class="">
`async Task` in C#. However, with 1, we lose the benefit of static<br class="">
checks by the compiler. Because both of `fooAsync()` without `await`<br class="">
and `await fooAsync()` are allowed, even if we want it to work like<br class="">
`async Task` in C# and forget to mark `await`, the compiler tell us<br class="">
nothing and it works like `async Void` in C#. It causes unexpected<br class="">
behaviors. It is hard to fix such kinds of bugs. So I think<br class="">
introducing `beginAsync` is better.<br class="">
<br class="">
--<br class="">
Yuta<br class="">
<br class="">
<br class="">
2017-11-12 10:23 GMT+09:00 Yuta Koshizawa via swift-evolution<br class="">
<<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class="">
<div class="HOEnZb"><div class="h5">> 2017-11-12 2:57 GMT+09:00 Adam Kemp <<a href="mailto:adam.kemp@apple.com" class="">adam.kemp@apple.com</a>>:<br class="">
>><br class="">
>><br class="">
>>> On Nov 11, 2017, at 6:24 AM, Yuta Koshizawa <<a href="mailto:koher@koherent.org" class="">koher@koherent.org</a>> wrote:<br class="">
>>><br class="">
>>> If you replace `async` with `throws`, you can get answers.<br class="">
>>><br class="">
>>><br class="">
>>>> Can you declare an async closure variable?<br class="">
>>><br class="">
>>> Yes. Like `let throwingClosure:() throws -> Void = { ... }`.<br class="">
>>><br class="">
>>><br class="">
>>>> Can a non-async closure be passed to a function expecting a async closure?<br class="">
>>><br class="">
>>> Yes. Like we can pass `() -> Void` to a function expecting a throwing<br class="">
>>> closure `() throws -> Void`.<br class="">
>>><br class="">
>>> It is possible because `(Foo) throws -> Bar` is a supertype of `(Foo)<br class="">
>>> -> Bar`. `(Foo) async -> Bar` is a supertype of `(Foo) -> Bar` in the<br class="">
>>> same way.<br class="">
>>><br class="">
>>> To treat an async function as a sync function is legal. It is similar<br class="">
>>> to make a `Promise` by `Promise(value)` which is completed<br class="">
>>> immediately.<br class="">
>>><br class="">
>>><br class="">
>>>> Can an async closure be passed to a function expecting a non-async closure?<br class="">
>>><br class="">
>>> No. `() -> Void` is a subtype of `() async -> Void`. It is same as<br class="">
>>> passing `() throws -> Void` to a function expecting `() -> Void` is<br class="">
>>> not allowed.<br class="">
>><br class="">
>> But why not? Just asserting that it must work the same as throws<br class="">
>> is not a convincing argument. You have to justify why it must work<br class="">
>> that way. I think there is good reason to allow it, which I have described.<br class="">
>> What reason is there to disallow it?<br class="">
><br class="">
> `() async -> Void` needs to be called with `await` because it prevents<br class="">
> us from forgetting handling asynchronous operations.<br class="">
><br class="">
> If we use callbacks to handle asynchronous operations, it is shown to<br class="">
> us by a compiler as a compilation error.<br class="">
><br class="">
> ```<br class="">
> func fooAsync(_ handler: () -> Void) -> Void { ... }<br class="">
><br class="">
> fooAsync() // compilation error<br class="">
><br class="">
> fooAsync {<br class="">
> // handles a completion event here<br class="">
> }<br class="">
> ```<br class="">
><br class="">
> With proposed `async/await`, it is realized similarly like below.<br class="">
><br class="">
> ```<br class="">
> func fooAsync() async -> Void { ... }<br class="">
><br class="">
> fooAsync() // compilation error<br class="">
><br class="">
> await fooAsync()<br class="">
> // handles a completion event here<br class="">
> ```<br class="">
><br class="">
> However, if async void functions work like `beginAsync`, we can easily<br class="">
> forget it and it can cause unexpected behaviors.<br class="">
><br class="">
> ```<br class="">
> func fooAsync() async -> Void { ... }<br class="">
><br class="">
> fooAsync() // OK<br class="">
> // hard to know this line is executed asynchronously<br class="">
> ```<br class="">
><br class="">
> Readability also suffers seriously. If we don't know `bar` in the<br class="">
> following code is a async function, it is impossible to expect lines<br class="">
> after `baz()` are executed asynchronously.<br class="">
><br class="">
> ```<br class="">
> foo()<br class="">
> bar()<br class="">
> baz()<br class="">
> qux()<br class="">
> ```<br class="">
><br class="">
><br class="">
>>>> It’s weird to me that we would allow you to have async void closures but not async void functions<br class="">
>>><br class="">
>>> I am not sure what you mean. "async void closures" and "async void<br class="">
>>> functions" have a same type. Following two are almost same.<br class="">
>>><br class="">
>>> ```<br class="">
>>> func foo() async -> Void { ... }<br class="">
>>> let foo: () async -> Void = { ... }<br class="">
>>> ```<br class="">
>><br class="">
>> What started this thread is my suggestion that you should be able to write<br class="">
>> an async void function. The current proposal doesn’t allow that. That’s why<br class="">
>> you have to use beginAsync.<br class="">
>><br class="">
>> I don’t think that makes sense. It sounds like you also think that would be strange,<br class="">
>> hence your assumption that you could.<br class="">
><br class="">
> By the reasons I wrote above, we need `await` even for async void<br class="">
> functions for checks by compilers. Then it is required to provide a<br class="">
> way to write entry points of async functions. That is `beginAsync`.<br class="">
><br class="">
> --<br class="">
> Yuta<br class="">
> ______________________________<wbr class="">_________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</div></div></blockquote></div><br class=""></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>