[swift-evolution] async void
Wallacy
wallacyf at gmail.com
Thu Nov 9 13:02:19 CST 2017
Before i make a comment on this topic i need to confirm something:
On original proposal, this:
func processImageData1(completionBlock: (result: Image) -> Void) {
loadWebResource("dataprofile.txt") { dataResource in
loadWebResource("imagedata.dat") { imageResource in
decodeImage(dataResource, imageResource) { imageTmp in
dewarpAndCleanupImage(imageTmp) { imageResult in
completionBlock(imageResult)
}
}
}
}
}
Is converted to this:
func processImageData1() async -> Image {
let dataResource = await loadWebResource("dataprofile.txt")
let imageResource = await loadWebResource("imagedata.dat")
let imageTmp = await decodeImage(dataResource, imageResource)
let imageResult = await dewarpAndCleanupImage(imageTmp)
return imageResult
}
And has other sentences explain that await will not block the thread etc...
So for me, this:
func OnButtonClicked(_ sender:AnyObject) {
let button = sender as! UIButton
button.isEnabled = false
beginAsync {
await DoSomethingAsync()
button.isEnabled = true
}
}
Does not make any sense... Because await will not block the thread we can
assume (like the exemple on proposal) that compiler will actually do the
same what we will do using GDC and pick everyone to until the context ends
and encapsulate as completion handle to the away call.
So we will only have this:
func OnButtonClicked(_ sender:AnyObject) {
let button = sender as! UIButton
button.isEnabled = false
await DoSomethingAsync()
button.isEnabled = true
}
I don't know how to handle reentrante or something like that, but the
proposal give me the impression this behavior.
In the other way, await will block the thread!
I know the proposal give us this exemple:
@IBAction func buttonDidClick(sender:AnyObject) {
// 1 beginAsync {
// 2 let image = await processImage()
imageView.image = image
}
// 3}
But this is different, because "3" will be fired before "2".
And this one:
@IBAction func buttonDidClick(sender:AnyObject) {
beginAsync {
let image = await processImageData()
// Do the update on the main thread/queue since it owns imageView.
mainQ.async {
imageView.image = image
}
}
}
Does not make any sense too.
The only way to await to do not block the thread is make a early return
like beginAsync and encapsulate as completion handle the rest of the code.
If not, i don't see how the first exemple of the proposal will be made.
Em qua, 8 de nov de 2017 às 15:55, Adam Kemp via swift-evolution <
swift-evolution at swift.org> escreveu:
> (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/>.
> Task happens to have a GetAwaiter (<
> 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>),
> 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>:
>
>> 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> 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 ),
>> > `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
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> omochimetaru
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171109/67a8d91d/attachment.html>
More information about the swift-evolution
mailing list