Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

My argument goes like this: 1. You don't need async/await to write a powerful future type; you can use the underlying threads just as well, i.e. future with async/await is no better than future without. 2. Since future is more powerful, thread control, cancel, and timeout, people should be

Re: [swift-evolution] [Concurrency] async/await + actors

I think we would be better off with a future type rather than async/await since they can offer timeout, cancel, and control over which thread execution occurs on. -- Howard. On 26 August 2017 at 00:06, Cavelle Benjamin via swift-evolution < swift-evolution@swift.org> wrote: > Disclaimer: not

Re: [swift-evolution] New async keyword usage

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

Re: [swift-evolution] New async keyword usage

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

Re: [swift-evolution] New async keyword usage

> On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise > wrote: > > = >> Jonathan Hull jhull at gbis.com > >> This looks somewhat similar to a future, but you can’t interact with it as a

Re: [swift-evolution] [Concurrency] async/await + actors

I’m not sure I understand. What is the connection between references and deadlocks? > On Aug 25, 2017, at 1:07 PM, Marc Schlichte > wrote: > > >> Am 25.08.2017 um 19:08 schrieb Adam Kemp via swift-evolution >>

Re: [swift-evolution] [Pitch] Improving KeyPath

> On Aug 25, 2017, at 3:54 PM, Logan Shire wrote: > > How would you feel about wrapping the existing functions on > _KVOKeyPathBridgeMachinery: > > @nonobjc fileprivate static func _bridgeKeyPath(_ keyPath:AnyKeyPath) -> > String > @nonobjc fileprivate static func

Re: [swift-evolution] [Pitch] Improving KeyPath

How would you feel about wrapping the existing functions on _KVOKeyPathBridgeMachinery: @nonobjc fileprivate static func _bridgeKeyPath(_ keyPath:AnyKeyPath) -> String @nonobjc fileprivate static func _bridgeKeyPath(_ keyPath:String?) -> AnyKeyPath? In extensions on String and AnyKeyPath

Re: [swift-evolution] New async keyword usage

> 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. Await does not block the current queue. You can imagine that

Re: [swift-evolution] New async keyword usage

On 25 août 2017 18:31 -0400, Jonathan Hull , 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()

Re: [swift-evolution] New async keyword usage

> how would you accomplish the following under the current proposal? We could implement a Future type (as imagined in the async/await proposal), which would enable something like this: let futureA = Future { await longCalculationA() } let futureB = Future { await

Re: [swift-evolution] New async keyword usage

First of all, thank you to everyone for reacting ! :) Taking the messages in chronological order : > Wallacy > Interesting, its syntax seems to improve the "fire and forget" issue. > > @IBAction func buttonClicked() { > async downloadAndUpdateImageView() > }

Re: [swift-evolution] New async keyword usage

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

Re: [swift-evolution] New async keyword usage

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

Re: [swift-evolution] New async keyword usage

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 wrote: > > Probably with: > > let a = longCalculationA() > let b = longCalculationB() //b doesn’t wait

Re: [swift-evolution] New async keyword usage

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

Re: [swift-evolution] New async keyword usage

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 =

Re: [swift-evolution] New async keyword usage

I actually really like the idea of using ‘async' to start a computation in a non-blocking way. It is extremely common in real-world code to want to start a few computations/downloads at once in the background and then use the results together... I think full-fledged futures could be a

Re: [swift-evolution] [Pitch] Improving KeyPath

> On Aug 25, 2017, at 1:45 PM, Eagle Offshore wrote: > > >> On Aug 25, 2017, at 1:35 PM, Joe Groff > > wrote: >> >> What do you mean exactly by traits? That's an overloaded term. > > >

Re: [swift-evolution] [Pitch] Improving KeyPath

> On Aug 25, 2017, at 1:27 PM, Eagle Offshore wrote: > > Reflection mechanisms in general would let one make things like Codable and > Keypaths simply a library capability/protocol extension rather than the > special case one trick pony it is now. > > More than any

Re: [swift-evolution] [Pitch] Improving KeyPath

Reflection mechanisms in general would let one make things like Codable and Keypaths simply a library capability/protocol extension rather than the special case one trick pony it is now. More than any other feature discussed, full access to meta data such as memory layouts is the thing I most

Re: [swift-evolution] New async keyword usage

Makes sense. But if i'm reading its right (and the original proposal too), in this case we don't have only a syntax sugar, we actually gain another ways to use. First, because Future actually need another proposal, and beginAsync (to me) does not apear to be that rare! "Fire and Forget" is

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 25.08.2017 um 19:08 schrieb Adam Kemp via swift-evolution > : > > I understand what you’re saying, but I just think trying to make synchronous, > blocking actor methods goes against the fundamental ideal of the actor model, > and it’s a recipe for disaster.

Re: [swift-evolution] [Pitch] Improving KeyPath

> On Aug 23, 2017, at 11:18 PM, Logan Shire via swift-evolution > wrote: > > Hey folks! > > Recently I’ve been working on a small library which leverages the Swift 4 > Codable protocol > and KeyPaths to provide a Swift-y interface to CoreData. (It maps back and >

Re: [swift-evolution] typed throws

on Fri Aug 25 2017, John McCall wrote: On Aug 25, 2017, at 12:18 PM, Dave Abrahams via swift-evolution wrote: on Fri Aug 18 2017, Joe Groff wrote: On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 25, 2017, at 9:54 AM, Thomas wrote: > > I'd tend to think non-FIFO actor messaging will cause more trouble than > potential deadlocks. I'm re-reading the proposal and it seems to go this way > as well: > > "An await on an actor method suspends the current task,

Re: [swift-evolution] [Concurrency] async/await + actors

> On 25 Aug 2017, at 18:30, Adam Kemp wrote: > > > >> On Aug 25, 2017, at 1:14 AM, Thomas > > wrote: >>> On 25 Aug 2017, at 01:15, Adam Kemp >> > wrote: >>> I don’t think

Re: [swift-evolution] typed throws

> On Aug 25, 2017, at 12:18 PM, Dave Abrahams via swift-evolution > wrote: > on Fri Aug 18 2017, Joe Groff wrote: > >>> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] [Concurrency] async/await + actors

Cancellation and time out can be built into futures, and async/await can interact with futures. I don’t think we need async/await itself to support either of those. Just as a real-world example, C#’s async/await feature doesn’t have built-in timeout or cancellation support, but it’s still easy

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 25, 2017, at 1:14 AM, Thomas wrote: >> On 25 Aug 2017, at 01:15, Adam Kemp > > wrote: >> I don’t think await should cause the actor’s queue (or any queue) to be >> suspended. Actor methods should not block waiting

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

> On Aug 25, 2017, at 12:34 AM, Howard Lovatt wrote: > > In particular a future that is cancellable is more powerful that the > proposed async/await. It's not more powerful; the features are to some degree disjoint. You can build a Future abstraction and then use

Re: [swift-evolution] typed throws

on Fri Aug 18 2017, Joe Groff wrote: >> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution >> wrote: >> >> Essentially, you give Error a tagged-pointer representation to allow >> payload-less errors on non-generic error types to

Re: [swift-evolution] typed throws

on Thu Aug 17 2017, John McCall wrote: >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson

Re: [swift-evolution] [Concurrency] async/await + actors

Disclaimer: not an expert Question I didn’t see any where the async is required to time out after a certain time frame. I would think that we would want to specify both on the function declaration side as a default and on the function call side as a customization. That being said, the return

Re: [swift-evolution] [Concurrency] async/await + actors

> On 25 Aug 2017, at 10:14, Thomas via swift-evolution > wrote: > > >> On 25 Aug 2017, at 01:15, Adam Kemp > > wrote: >> >> >> >>> On Aug 24, 2017, at 3:15 PM, Thomas >>

Re: [swift-evolution] [Concurrency] async/await + actors

> On 25 Aug 2017, at 10:14, Thomas via swift-evolution > wrote: > > >> On 25 Aug 2017, at 01:15, Adam Kemp > > wrote: >> >> >> >>> On Aug 24, 2017, at 3:15 PM, Thomas >>

Re: [swift-evolution] [Concurrency] async/await + actors

> On 25 Aug 2017, at 10:17, Thomas via swift-evolution > wrote: > >> >> On 25 Aug 2017, at 09:04, Marc Schlichte > > wrote: >> >> >>> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution

Re: [swift-evolution] [Concurrency] async/await + actors

> On 25 Aug 2017, at 09:04, Marc Schlichte > wrote: > > >> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution >> >: >> >>> >>> Yes, I think it is mandatory that we continue on the callers

Re: [swift-evolution] [Concurrency] async/await + actors

> On 25 Aug 2017, at 01:15, Adam Kemp wrote: > > > >> On Aug 24, 2017, at 3:15 PM, Thomas > > wrote: >> >> >>> On 24 Aug 2017, at 23:47, Adam Kemp >> > wrote: >>> >>>

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 25.08.2017 um 01:15 schrieb Adam Kemp via swift-evolution > : > > I don’t think await should cause the actor’s queue (or any queue) to be > suspended. Actor methods should not block waiting for asynchronous things. > That’s how you get deadlocks. If an actor

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

Using a Future library, see below, you can do what you want. In particular a future that is cancellable is more powerful that the proposed async/await. Here is an extended example of a typical UI task including users cancelling tasks that is written using a future library (see below):

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution > : > >> >> Yes, I think it is mandatory that we continue on the callers queue after an >> `await ` on some actor method. >> >> If you `await` on a non-actor-method though, you would have to changes >>