> On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise
> <[email protected]> wrote:
>
> =============================================================
>> Jonathan Hull jhull at gbis.com <http://gbis.com/>
>
>> This looks somewhat similar to a future, but you can’t interact with it as a
>> separate type of object. The value above is just a UIImage, but with a
>> compiler flag/annotation that forces me to call await on it before it can be
>> accessed/used. The compiler has a lot more freedom to optimize/reorganize
>> things behind the scenes, because it doesn’t necessarily need to make an
>> intermediate object.
>
>
> As for the message of Wallacy I'd be interested the pros and cons of hiding
> the implementation details ! :)
>
>
>> To prove (or potentially disprove) my assertion that this is not just sugar,
>> how would you accomplish the following under the current proposal?
>>
>> let a = async longCalculationA()
>> let b = async longCalculationB() //b doesn’t wait for a to complete
>> before starting
>> let c = async longCalculationC() //c doesn’t wait for a or b
>> let result = await combineCalculations(a: a, b: b, c: c) //waits until
>> a, b, and c are all available
>
>
> Would this be implemented differently than with Futures? I don't have much
> experience with concurrency, but I don't see how this would be handled
> differently than by using Futures, internally ? (at least for this case)
>
It looks/behaves very similar to futures, but would potentially be implemented
differently. The main difference is that the resulting type is actually the
desired type (instead of Future<Type>) with a compiler flag saying that it
needs to call await to be used. Behind the scenes, this could be implemented
as some sort of future, but the compiler has a lot more freedom to rearrange
things to be much more efficient because there is no affordance for the user to
introspect or cancel. So for example, it might actually change:
let image = async downloadImage()
let size = await image.size
to:
let size = await downloadImage().size
This would depend on the other code around it, but the compiler has much more
freedom to avoid creating intermediate values, or even to create different
types of intermediate values which are more efficient for the situation at hand.
Given that as a base, it would be trivial to create a framework offering true
Futures (which allow cancelling, etc…)
Thanks,
Jon
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
