[swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[David Sweeris]

> On Aug 10, 2016, at 5:36 PM, Slava Pestov <spestov at apple.com> wrote:
> 
> 
>> On Aug 10, 2016, at 3:34 PM, Christopher Kornher <ckornher at me.com> wrote:
>> 
>> Would this prevent an object from being “known" to multiple threads? …multiple queues? If so, it would be overly restrictive for a general-purpose language. I assume that the plan includes a way to allow “unsafe” behavior to support other concurrency models.
>> 
> 
> To be clear I'm not presenting any ideas for Swift here, just critiquing Go's model.
> 
> Yes, I'm just talking about 'safe' language features for passing immutable data between threads. This would not preclude other forms of concurrency from existing in the language, such as locks, atomics, etc. But I think if a user writes code with only message passing, the language should ensure that the result is free from data races. Go does not do that, which is unfortunate.
> 
Oh, *that* I’ll agree with… I was just talking about situations where there is no “safe” way to do it (for whatever your language’s/compiler’s idea of “safe” is). For example, maybe you really do need to interpret a 64-bit chunk of data as an Int64, even though the compiler is convinced it’s a Double. We can do that in Swift through the various “unsafe” functions, which is where they belong because 99.99% of the time that’s a bad idea. That 0.01% though…

- Dave Sweeris