<div dir="ltr"><div>I totally agree Yuta's suggestion.</div><div>beginAsync does not have to accept function which throws.</div><div><br></div><div>> Adam</div><div><br></div><div>I don't think that C# style async void function invodation matchs swift.</div><div><br></div><div>If we can do, following code can be compile.</div><div><br></div><div>```swift</div><div>async func sendMessage() -> Void { ... }</div><div><br></div><div>func onButtonClick() {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>sendMessage()</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>showAlert("message sent")</div><div>}</div><div>```</div><div><br></div><div>But in this case, the logic actually programmer desired is </div><div>showing alert after sendMessage completed.</div><div>Above style code is not easy readable about execution fall through</div><div>without waiting completion of sendMessage to showAlert.</div><div>With this rule, compiler can not help us to find such mistaken code.</div><div><br></div><div>This seems like unchecked exception problem in other languages.</div><div>Keep starting asynchronous invodation explicit suck like </div><div>throwing function invocation explicitly marked with `try` or `do`.</div></div><br><div class="gmail_quote"><div dir="ltr">2017年11月8日(水) 13:28 Adam Kemp via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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#.<br>
<br>
Swift has the advantage in this case of being able to statically verify that a function doesn’t throw so we can do better.<br>
<br>
So I would argue in favor of not allowing beginAsync to throw at all.<br>
<br>
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.<br>
<br>
> On Nov 7, 2017, at 7:04 PM, Yuta Koshizawa via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Although I posted about this topic before, let me post this again<br>
> because I think it is important and I have received just few replies.<br>
> Sorry if I missed some discussion about it.<br>
><br>
> In the proposal (<br>
> <a href="https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619" rel="noreferrer" target="_blank">https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619</a> ),<br>
> `beginAsync` has the following signature.<br>
><br>
> ```<br>
> func beginAsync(_ body: () async throws -> Void) rethrows -> Void<br>
> ```<br>
><br>
> However, I think it is better to forbid `body` to throw errors, that<br>
> is to say, to change its signature to the following one.<br>
><br>
> ```<br>
> func beginAsync(_ body: () async -> Void) -> Void<br>
> ```<br>
><br>
> Even if `beginAsync` allows that `body` throws errors, it can rethrow<br>
> ones which are thrown before only first `await` call. In following<br>
> cases, `beginAsync` just has to make the program crash when `foo`<br>
> throws an error. It breaks safety for error handing by typed<br>
> propagation realized by `throws/try`.<br>
><br>
> ```<br>
> // throws errors asynchronously<br>
> func foo() async throws -> Int { ... }<br>
><br>
> do {<br>
> beginAsync {<br>
> let a = try await foo()<br>
> // uses `a` here<br>
> }<br>
> } catch _ {<br>
> // never reaches here<br>
> }<br>
> ```<br>
><br>
> If `beginAsync` forbid `body` to throw errors, it can be detected as a<br>
> compilation error and is possible to fix it as follows.<br>
><br>
> ```<br>
> beginAsync {<br>
> do {<br>
> let a = try await foo()<br>
> // uses `a` here<br>
> } catch _ {<br>
> // error handling<br>
> }<br>
> }<br>
> ```<br>
><br>
> And even when we want to write `try` calls in `beginAsync` before<br>
> first `await` call, those lines can be moved before the `beginAsync`<br>
> call.<br>
><br>
> ```<br>
> // before ( `beginAsync` marked with `rethrows` )<br>
> do {<br>
> beginAsync {<br>
> let a = try bar()<br>
> let b = try baz()<br>
> let c = await qux(a, b)<br>
> // uses `c` here<br>
> }<br>
> catch _ {<br>
> // error handling<br>
> }<br>
><br>
> // after ( `beginAsync` without `rethrows` )<br>
> do {<br>
> let a = try bar()<br>
> let b = try baz()<br>
> beginAsync {<br>
> let c = await qux(a, b)<br>
> // uses `c` here<br>
> }<br>
> catch _ {<br>
> // error handling<br>
> }<br>
> ```<br>
><br>
> So the functionalities of `beginAsync` seems be kept even if it forbid<br>
> `body` to throw errors.<br>
><br>
> What do you think about it?<br>
><br>
> --<br>
> Yuta<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>omochimetaru</div></div></div>