One small note on the async keyword, I would put it first unlike throws:
async func myFunc() -> Type {
return await typeProducer()
}
This improves the readability for the consumer .
Also async implies throws as it denotes wrapping an await call, not sure if we
need to specify it as well.
On Aug 26, 2017, 14:59 -0400, Goffredo Marocchi via swift-evolution
<[email protected]>, wrote:
>
>
> Sent from my iPhone
>
> On 26 Aug 2017, at 18:36, Adam Kemp via swift-evolution
> <[email protected]> wrote:
>
> > C# had futures (in the form of the Task Parallel Library) before it had
> > async/await. If you could see how much async/await has revolutionized C#
> > programming you would not be making this argument. It is night and day.
> > Asynchronous code is so much clearer with this feature than without. You
> > can write code the is simpler and safer at the same time.
> >
> > This isn’t an either/or proposition. We should have both, and they should
> > work together.
> >
>
> +1
>
> > --
> > Adam Kemp
> >
> > On Aug 25, 2017, at 10:08 PM, Howard Lovatt via swift-evolution
> > <[email protected]> wrote:
> >
> > > 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
> > > > <[email protected]> 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 <[email protected]>, wrote:
> > > > > >
> > > > > > > On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise
> > > > > > > <[email protected]> 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
> > > > > [email protected]
> > > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > >
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > [email protected]
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > _______________________________________________
> > swift-evolution mailing list
> > [email protected]
> > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
