[swift-evolution] New async keyword usage

[Howard Lovatt]

I just don't see that async/await adds enough to warrant a language change.
You can write Future on top of GCD and a future type can do more, like
having a cancel, having a timeout, and giving control over what thread is
used.

  -- Howard.

On 26 August 2017 at 10:57, Florent Vilmart via swift-evolution <
swift-evolution at swift.org> wrote:

> Isn’t async / await an evolution over Promises / Tasks / Futures? AFAIK in
> JS, any function that returns a promise can be ‘await’ upon, and
> underneath, to be able to await, a function has to return a promise.
> Marking a function async in JS, tells the consumer that some await are
> going on inside, and it’s impossible to use await outside of an async
> marked function. I believe swift is going that direction too. Futures /
> Promises are the foundation on which async / await can truly express as it
> formalizes the boxing of the result types.
> What would be interesting is async being based on a protocol FutureType
> for example, so you can bring your own library and yet, leverage async /
> await
>
> On Aug 25, 2017, 20:50 -0400, Jonathan Hull <jhull at gbis.com>, wrote:
>
>
> On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise <
> trevor.annedenise at icloud.com> wrote:
>
> =============================================================
>
> Jonathan Hull jhull at 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170826/5e9442cc/attachment.html>