[swift-evolution] async void
Adam Kemp
adam_kemp at apple.com
Wed Nov 8 11:55:03 CST 2017
(I changed the subject since it’s not really the same topic)
The short answer is that this code has the same problem even without async void:
func sendMessage() {
beginAsync {
// …
}
}
func onButtonClick() {
sendMessage()
showAlert("message sent")
}
If you want someone to be able to wait for something to finish then you make your function awaitable. So what does that mean for an async function that doesn’t really return anything? To understand what I’m thinking it helps to understand how C# does it, since that’s the model I’m proposing, and I think it works really well. In C# it works like this:
void NoReturn() { }
int IntReturn() { return 0; }
async Task NoReturnAsync() { await Task.Yield(); }
async Task<int> IntReturnAsync() { await Task.Yield(); return 0; }
async void NoReturnAsyncVoid() { await Task.Yield(); }
async Task Caller()
{
NoReturn();
int i = IntReturn();
await NoReturnAsync();
int j = await IntReturnAsync();
NoReturnAsync(); // this cannot be awaited
}
An important difference is that in C# the async keyword does not make a function awaitable. Notice how NoReturnAsyncVoid is marked as “async”, but the caller cannot use “await” with it. So what do you do if you want to wait for it to finish, like in your example? Well notice that another function NoReturnAsync doesn’t actually appear to return anything, even though its return type is Task. The compiler transforms the function into pieces where the first piece (the one actually called by the caller) returns a Task object. A bare Task is only used for waiting for completion, whereas a Task<T> also holds a return value. When you make a function that returns T async then you change the return type to Task<T>. When you make a void function async and want to allow the caller to wait for it to finish then you change the void to Task. When you make a void function async but want the caller to not wait for it to finish then you leave it as void.
This is subtle, but consider this alternative form:
void NoReturn() { }
int IntReturn() { return 0; }
Task NoReturnAsync() { return Task.Yield(); }
Task<int> IntReturnAsync() { return Task.Yield(); return 0; }
void NoReturnAsyncVoid() { Task.Yield(); }
async Task Caller()
{
NoReturn();
int i = IntReturn();
await NoReturnAsync();
int j = await IntReturnAsync();
NoReturnAsync(); // this cannot be awaited
}
I changed all of the “async" functions above except for Caller by removing the “async” keyword and (where applicable) added return statements. Now none of those functions is async, but they are functionally equivalent. Notice that the async Caller (which I didn’t change at all) can still await the ones that return Task or Task<T>. That’s because, again, in C# the async keyword does not mean “this can be awaited”. Being able to await a function call is orthogonal to whether that function is marked as async.
Async means only one thing: that function can use the await keyword, and it will be decomposed by the compiler accordingly. So what can you await? Anything that’s “awaitable”. :) Basically if the return type of the function has a GetAwaiter method that returns a type that has a few properties and methods then you can use await on that function. This is described here: <https://blogs.msdn.microsoft.com/pfxteam/2011/01/13/await-anything/ <https://blogs.msdn.microsoft.com/pfxteam/2011/01/13/await-anything/>>. Task happens to have a GetAwaiter (<https://msdn.microsoft.com/en-us/library/system.threading.tasks.task.getawaiter(v=vs.110).aspx <https://msdn.microsoft.com/en-us/library/system.threading.tasks.task.getawaiter(v=vs.110).aspx>>) method that returns a TaskAwaiter (<https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.taskawaiter(v=vs.110).aspx>) <https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.taskawaiter(v=vs.110).aspx%3E)>, which happens to have an IsCompleted property and GetResult and OnCompleted methods.
You can make any type awaitable by supplying a suitable GetAwaiter implementation, even using an extension method. I think this could probably be done with protocols and extensions in Swift.
Back to the problem you described: wouldn’t an async void method be confusing to callers who expect it to finish before returning? Obviously if it’s a function that requires the caller to wait before continuing then it should be made awaitable. So in C# you wouldn’t make an async void function that you expected people to want to wait for, and in C# you have that choice: you can make an awaitable function that returns nothing to the awaiter.
The question, though, is “are there any use cases for an async function that doesn’t require its caller to wait for it?” Or, put another way, is there a use case for an async function that a caller can call as if it’s just any other void function? There definitely are multiple use cases for that, but the most important one probably is event callbacks, most often UI event callbacks. Think of a button click handler. When a button is clicked maybe you want to start some async task. This is a common pattern in .Net:
private async void OnButtonClicked(object sender, EventArgs e)
{
Button button = (Button)sender;
button.IsEnabled = false;
await DoSomethingAsync();
button.IsEnabled = true;
}
In Swift with the current proposal that would be something like this:
func OnButtonClicked(_ sender:AnyObject) {
let button = sender as! UIButton
button.isEnabled = false
beginAsync {
await DoSomethingAsync()
button.isEnabled = true
}
}
If you compare those two implementations I think it’s obvious which one is clearer. The advantage of async/await is that it makes async code look like sync code by preserving the logical code flow. It makes the compiler do the hard work of splitting the function up. If you have to use beginAsync then you’re forced to do what the compiler could do for you. You have to think about where it goes, and how much should be inside that block or outside. Someone might be tempted to write that method above like this:
func OnButtonClicked(_ sender:AnyObject) {
let button = sender as! UIButton
button.isEnabled = false
beginAsync {
await DoSomethingAsync()
}
button.isEnabled = true
}
That code would be wrong. Is that obvious at a glance? I don’t think so. What about this?
func OnButtonClicked(_ sender:AnyObject) {
beginAsync {
let button = sender as! UIButton
button.isEnabled = false
await DoSomethingAsync()
button.isEnabled = true
}
}
That code does the right thing. So why wouldn’t you always write it that way? Serious question: what is the use case for using beginAsync for only part of a function? It looks like every example in Chris’s proposal wraps the entire contents of the function (except for one in an initializer).
If beginAsync is used almost exclusively to wrap the entire contents of void functions that you want to be async then why wouldn’t we just make it possible to make that function itself async and use await directly? It seems much clearer to me. async/await is already kind of confusing for newcomers, and I think beginAsync makes it worse by introducing a new concept that is easily misused and shouldn’t be necessary.
> On Nov 7, 2017, at 10:22 PM, omochi.metaru <omochi.metaru at gmail.com> wrote:
>
> I totally agree Yuta's suggestion.
> beginAsync does not have to accept function which throws.
>
> > Adam
>
> I don't think that C# style async void function invodation matchs swift.
>
> If we can do, following code can be compile.
>
> ```swift
> async func sendMessage() -> Void { ... }
>
> func onButtonClick() {
> sendMessage()
> showAlert("message sent")
> }
> ```
>
> But in this case, the logic actually programmer desired is
> showing alert after sendMessage completed.
> Above style code is not easy readable about execution fall through
> without waiting completion of sendMessage to showAlert.
> With this rule, compiler can not help us to find such mistaken code.
>
> This seems like unchecked exception problem in other languages.
> Keep starting asynchronous invodation explicit suck like
> throwing function invocation explicitly marked with `try` or `do`.
>
> 2017年11月8日(水) 13:28 Adam Kemp via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
> I think I agree with this. beginAsync is similar to C#’s async void functions, and one of the gotchas in C# is that it is never safe to allow an exception to be thrown from an async void function. The reason is that if the exception happens after the continuation then there won’t be any application code above it to catch that exception. As a result, the built in behavior is to immediately crash the app.
>
> This is unavoidable in C# where it’s impossible to write a function that is guaranteed not to throw. The semantics of exception throwing don’t allow for that in C#.
>
> Swift has the advantage in this case of being able to statically verify that a function doesn’t throw so we can do better.
>
> So I would argue in favor of not allowing beginAsync to throw at all.
>
> FWIW, I also still think it would be better if we allowed for async void functions instead of requiring beginAsync in the first place. If I had my way then we would have async void, but an async void would not be allowed to throw.
>
> > On Nov 7, 2017, at 7:04 PM, Yuta Koshizawa via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > Although I posted about this topic before, let me post this again
> > because I think it is important and I have received just few replies.
> > Sorry if I missed some discussion about it.
> >
> > In the proposal (
> > https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 <https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619> ),
> > `beginAsync` has the following signature.
> >
> > ```
> > func beginAsync(_ body: () async throws -> Void) rethrows -> Void
> > ```
> >
> > However, I think it is better to forbid `body` to throw errors, that
> > is to say, to change its signature to the following one.
> >
> > ```
> > func beginAsync(_ body: () async -> Void) -> Void
> > ```
> >
> > Even if `beginAsync` allows that `body` throws errors, it can rethrow
> > ones which are thrown before only first `await` call. In following
> > cases, `beginAsync` just has to make the program crash when `foo`
> > throws an error. It breaks safety for error handing by typed
> > propagation realized by `throws/try`.
> >
> > ```
> > // throws errors asynchronously
> > func foo() async throws -> Int { ... }
> >
> > do {
> > beginAsync {
> > let a = try await foo()
> > // uses `a` here
> > }
> > } catch _ {
> > // never reaches here
> > }
> > ```
> >
> > If `beginAsync` forbid `body` to throw errors, it can be detected as a
> > compilation error and is possible to fix it as follows.
> >
> > ```
> > beginAsync {
> > do {
> > let a = try await foo()
> > // uses `a` here
> > } catch _ {
> > // error handling
> > }
> > }
> > ```
> >
> > And even when we want to write `try` calls in `beginAsync` before
> > first `await` call, those lines can be moved before the `beginAsync`
> > call.
> >
> > ```
> > // before ( `beginAsync` marked with `rethrows` )
> > do {
> > beginAsync {
> > let a = try bar()
> > let b = try baz()
> > let c = await qux(a, b)
> > // uses `c` here
> > }
> > catch _ {
> > // error handling
> > }
> >
> > // after ( `beginAsync` without `rethrows` )
> > do {
> > let a = try bar()
> > let b = try baz()
> > beginAsync {
> > let c = await qux(a, b)
> > // uses `c` here
> > }
> > catch _ {
> > // error handling
> > }
> > ```
> >
> > So the functionalities of `beginAsync` seems be kept even if it forbid
> > `body` to throw errors.
> >
> > What do you think about it?
> >
> > --
> > Yuta
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> --
> omochimetaru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171108/0d612507/attachment.html>
More information about the swift-evolution
mailing list