> On Aug 24, 2017, at 3:59 PM, Adam Kemp <[email protected]> wrote:
>
> I generally agree that async/await could be more valuable built on top of
> library support. I did have one nitpick about this:
>
>> On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> In other words:
>>
>> async func doSomething() → Value { … }
>>
>> Let value = await doSomething()
>>
>> Becomes sugar for this pseudocode:
>>
>> func doSomething() → Future<Value> { … }
>>
>> let value = doSomething().value // or however you “wait” for the value
>
> These two examples do fundamentally different things. The await version
> doesn’t block the thread (it would return to the caller instead of blocking
> and pick up again later). The .value version would have to block. In C# this
> is equivalent to using the .Result property of the Task<T> type. However,
> that is strongly discouraged because it easily leads to deadlocks.
>
> A closer equivalent would be something like this:
>
> func doSomething() -> Future<Value> { … }
>
> doSomething().continueWith { (future: Future<Value>) in
> let value = try? future.value
> }
>
> Now it’s asynchronous either way. The continuation block takes a
> Future<Value> so that you could do error handling (more complex error
> handling not shown).
That’s fine. I assumed it was blocking because it has a very prominent “wait”
in the name. 🤷♂️
>> I’m admittedly not very familiar with async/await or the actor pattern.
:)
Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
