[swift-evolution] New async keyword usage

[Florent Vilmart]

be doesn't wait if it's defined as

func longCalculationB() async -> SomeType

which would be helpful if it's a long calculation,

in the case it's

func longCalculationB() -> SomeType

That would probably be valid to put the async keyword front even though I would not be a big fan of that as you'd be executing on an indefinite queue a calculation that may not be thread safe.

async would be in that case a wrapper around dispatch_async  + semaphore


On 25 août 2017 18:08 -0400, Jonathan Hull <jhull at gbis.com>, wrote:
> Why wouldn’t b wait for a in this example?  If it is using futures, those aren’t available in the current proposal.
>
> > On Aug 25, 2017, at 3:02 PM, Florent Vilmart <florent at flovilmart.com> wrote:
> >
> > Probably with:
> >
> > let a = longCalculationA()
> > let b = longCalculationB() //b doesn’t wait for a to complete before starting
> > let c = longCalculationC() //c doesn’t wait for a or b
> > let (aResult, bResult, cResult) = await Future.collect(a, b, c) //waits until a, b, and c are all available
> >
> > On 25 août 2017 17:48 -0400, wrote:
> > >
> > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170825/e7e073d4/attachment.html>