> 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. Slava > >> On Aug 10, 2016, at 4:24 PM, Slava Pestov via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Aug 10, 2016, at 3:22 PM, David Sweeris <daveswee...@mac.com> wrote: >>> >>>> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> As I understand it, a big weakness of Go's model is that it does not >>>> actually prevent data races. There's nothing preventing you from sharing >>>> pointers to mutable values between tasks, but I could be wrong about this. >>> Is that bad? Sharing pointers seems like a cheap way to share data, and as >>> long as you know what you’re doing, why should the language get in the way? >>> Now, if said code really does have performance advantages over the “safer” >>> methods, and it really is safe because for whatever reason the race >>> condition can’t actually happen, the language (or library) ought to have a >>> way to express that without having to write “unsafe” code. In the meantime, >>> though, you’ve gotta ship something that runs and meets performance >>> requirements. >> >> Well, ideally, the type system would be able to enforce that values passed >> across thread boundaries are immutable. Rust's model allows this, I believe. >> >> The possibility of mutating shared state in an unprincipled manner is "bad" >> in the same sense that being able to call free() in C is "bad" -- it's an >> abstraction violation if you get it wrong. Compared to languages with >> automatic memory management, there are advantages (control over memory >> management) and disadvantages (fewer static guarantees). >> >> >>> >>> - Dave Sweeris >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
