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.
> 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
