(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.met...@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@swift.org
> <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> --
> omochimetaru
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
