-Pierre
> On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise
> <[email protected]> wrote:
>
>>
>> Le 18 sept. 2017 à 07:57, Pierre Habouzit <[email protected]
>> <mailto:[email protected]>> a écrit :
>>
>>> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
