Re: [swift-evolution] New async keyword usage

Chris's proposal is very explicit about the advantages of the async/await over the Future/Task, we don't need to rephrase here. The most obvious advantage of course is because "await" does not block the execution (Future.get() does). And the whole proposal about async/await/actors is very, very

Re: [swift-evolution] Two thoughts on concurrency

I don’t think that there are any simple rules that define “Complexity”. I hope that is not too off-topic... https://www.edwardtufte.com/tufte/books_vdqi > It makes sense to make a distinction between adding keywords/modifiers to implement a niche feature and implementing fairly well

Re: [swift-evolution] New async keyword usage

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

Re: [swift-evolution] New async keyword usage

Sent from my iPhone > On 26 Aug 2017, at 18:36, Adam Kemp via swift-evolution > 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

Re: [swift-evolution] New async keyword usage

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

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

> Le 26 août 2017 à 07:27, Howard Lovatt via swift-evolution > a écrit : > > 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 >

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

> Am 26.08.2017 um 02:03 schrieb Adam Kemp via swift-evolution > : > > I’m not sure I understand. What is the connection between references and > deadlocks? This is what I had in mind: To have a deadlock from async actor methods, you would need some mutual

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

Howard, with async / await, the code is flat and you don’t have to unowned/weak self to prevent hideous cycles in the callbacks. Futures can’t do that On Aug 26, 2017, 04:37 -0400, Goffredo Marocchi via swift-evolution , wrote: > With both he now built in promises in

Re: [swift-evolution] New async keyword usage

Thinking about it, wouldn't hiding the implementation of Future have the advantage of preventing people from returning Futures from functions ? This would allow to write this: func foo() async -> Future { let futureValue = Future { await someOtherFunc() } doSomethingElse()

Re: [swift-evolution] New async keyword usage

> Le 26 août 2017 à 07:07, Howard Lovatt a écrit : > > 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

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

With both he now built in promises in Node8 as well as libraries like Bluebird there was ample time to evaluate them and convert/auto convert at times libraries that loved callback pyramids of doom when the flow grows complex into promise based chains. Converting to Promises seems magical for

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

> On Aug 25, 2017, at 10:12 PM, Howard Lovatt via swift-evolution > wrote: > > 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. async/await is a