On 25 août 2017 18:31 -0400, Jonathan Hull <[email protected]>, wrote:
> But then it would need to be called with await under the current proposal,
> meaning that either:
>
> • b would await the calculation of a
>
> beginAsync {
> let a = await longCalculationA()
> let b = await longCalculationB() //This only calculates when a is finished
> }
why would it? the async modifier could very well be used to transform a sync
function into an async one, dispatching on a defined queue returning the
'Future' and resolving once the function completes.
I'm not sure why it's understood as all or nothing, AFAICU, await is just a way
to block the current queue and wait for a result from an async function.
beginAsync is a way to make sure we don't block the current execution queue.
something like
let a = await async longSynchrounousCall() would block the current execution
queue (because await) but the execution of the longSynchronousCall() would be
on a separate queue / block.
The question lays more in where the calls are executed, either they are
dispatched after, current block is suspended, runloop continues, and then the
block is re-entered upon returning. that would lead to some weird executions
flows.
>
> • or b would be executed while a is awaiting, but a and b would be in
> different scopes
>
> beginAsync{
> let a = await longCalculationA()
> }
> beginAsync{
> let b = await longCalculationB() //We can’t see ‘a’ anymore
> }
> //We can’t see ‘a’ or ‘b’ here to use them
>
> We could, also implement some sort of future, and then re-write our functions
> to take advantage of it, but this misses out on numerous compiler
> optimizations and requires our functions to be written with futures in mind.
> In my example, the functions can just be written as async, and they don’t
> care whether they are called with async or await.
>
> Thanks,
> Jon
>
> > On Aug 25, 2017, at 3:13 PM, Florent Vilmart <[email protected]> wrote:
> >
> > 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
