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 <[email protected]>, 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 <[email protected]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
