[swift-evolution] Question about async await

[Pierre Habouzit]

-Pierre

> On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise at icloud.com> wrote:
> 
>> 
>> Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre at habouzit.net <mailto:pierre at habouzit.net>> a écrit :
>> 
>>> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hello everyone,
>>> 
>>> I have a few questions about async await in Swift.
>>> 
>>> Say that you have :
>>> 
>>> func foo() async {
>>> 	print("Hey")
>>> 	await bar()
>>> 	print("How are you ?")
>>> }
>>> 
>>> First of all, am I right to say that :
>>> 1) If the bar function wasn't an async function, the thread would be blocked until bar returns, at this point print("How are you ?") would be executed and its only after that that the function calling foo() would get back "control"
>> 
>> I don't think you can quite call await without marking foo() as async (?).
> 
> 
> Yes, that's what I meant, case one would call foo() without await if it wasn't async.
> 
> 
>> 
>>> 2) Here (with async bar function), if bar() takes some time to execute,
>> 
>> Not quite, `await bar()` is afaict syntactic sugar for:
>> 
>> bar {
>>     printf("How are you ?");
>> }
>> 
>> Where bar used to take a closure before, the compiler is just making it for you. bar itself will be marked async and will handle its asynchronous nature e.g. using dispatch or something else entirely.
>> This has nothing to do with "time".
> 
> 
> If it's just syntactic sugar then how does this solve this issue mentioned in the concurrency manifesto ?
> "Beyond being syntactically inconvenient, completion handlers are problematic because their syntax suggests that they will be called on the current queue, but that is not always the case. For example, one of the top recommendations on Stack Overflow is to implement your own custom async operations with code like this (Objective-C syntax):"

"where" things run is not addressed by async/await afaict, but Actors or any library-level usage of it.

> 
> 
> Trevör
> 
> 
> 
>> 
>>> control is directly given back to the function calling foo() and, when bar() returns, print("How are you") will be executed.
>>> 
>>> 
>>> Second question about why async/await are needed:
>>> Since calling await must be done in an async function and since async function can only be called, then if we have :
>>> func baz() async {
>>> 	await foo()
>>> 	print("Something else")
>>> }
>>> 
>>> Does this mean that "print("Something else")" will actually be waiting for bar() (and foo()) to complete ?
>>> If this is right, then, what surprises me a little is that in this specific case, if all functions hadn't been async, then the execution order would have exactly been the same, am I right ?
>>> So why are async/await needed ? Except for clarity, what do they enable that wouldn't have been possible otherwise ? It's not exactly clear to me sometimes because even things like futures wouldn't seem impossible to build without async await.
>>> 
>>> About beginAsync, say that we do that on the main thread :
>>> beginAsync {
>>> 	await someAsyncFunction()
>>> }
>>> 
>>> Will someAsyncFunction() still be executed on the main thread if it was defined this way ?
>>> func someAsyncFunction() async {
>>> 	for element in manyElements {
>>> 		doSomethingLong(element)
>>> 	}
>>> }
>>> 
>>> In this case, when will the main "choose" to execute those instructions ?
>>> 
>>> 
>>> Thank you !
>>> 
>>> Trevör
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170918/810776d2/attachment.html>