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] Two thoughts on concurrency

> On Aug 24, 2017, at 9:17 PM, Félix Cloutier wrote: > > I feel that it's important to point out that this example feels weird because > even though the compiler doesn't treat "weak" as a reserved term, most > developers perceive it as one. I don't think that David

Re: [swift-evolution] Two thoughts on concurrency

I feel that it's important to point out that this example feels weird because even though the compiler doesn't treat "weak" as a reserved term, most developers perceive it as one. I don't think that David is worried that we're taking away all the cool words from the realm of identifiers; the

Re: [swift-evolution] Two thoughts on concurrency

> On Aug 24, 2017, at 8:57 PM, Chris Lattner via swift-evolution > wrote: > > On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution > > wrote: >> Keyword Explosion >> >> During the Great Access

Re: [swift-evolution] Two thoughts on concurrency

On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution wrote: > Keyword Explosion > > During the Great Access Control Wars of Swift 4, one of the points that kept > coming up was the reluctance to introduce a bazillion new keywords to address > all the cases

Re: [swift-evolution] Two thoughts on concurrency

Hi, Although `throws` and `async` are similar to return a `Result` and a `Future` respectively as you say, However, `try` and `await` are corresponding to `flatMap` theoretically. // `throws/try` func foo() throws -> Int { ... } func bar() throws -> Int { let a: Int = try foo() let b: Int =

Re: [swift-evolution] Two thoughts on concurrency

> On Aug 24, 2017, at 3:59 PM, Adam Kemp wrote: > > I generally agree that async/await could be more valuable built on top of > library support. I did have one nitpick about this: > >> On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution >>

Re: [swift-evolution] Two thoughts on concurrency

I generally agree that async/await could be more valuable built on top of library support. I did have one nitpick about this: > On Aug 24, 2017, at 1:59 PM, Dave DeLong via swift-evolution > wrote: > > In other words: > > async func doSomething() → Value { … } > >

Re: [swift-evolution] Two thoughts on concurrency

> Le 24 août 2017 à 22:59, Dave DeLong via swift-evolution > a écrit : > > Hi everyone, > > (the standard disclaimer of “I’m neither a compiler engineer nor a language > design expert” applies) > > I’ve been trying to keep up with all the discussion around

[swift-evolution] Two thoughts on concurrency

Hi everyone, (the standard disclaimer of “I’m neither a compiler engineer nor a language design expert” applies) I’ve been trying to keep up with all the discussion around concurrency going on, and I’m admittedly not very familiar with async/await or the actor pattern. However, a couple of