> On Aug 10, 2016, at 5:36 PM, Slava Pestov <spes...@apple.com> wrote: > > >> On Aug 10, 2016, at 3:34 PM, Christopher Kornher <ckorn...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
