> On Aug 18, 2017, at 2:15 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Aug 18, 2017, at 7:19 AM, Michel Fortin <michel.for...@michelf.ca >> <mailto:michel.for...@michelf.ca>> wrote: >> >> Great writeup. Here's a few comments about the manifesto, actors and value >> semantics specifically. >> >> >> # About actors and data isolation >> >> Can I call global functions like sin(x) in an actor? Surely you need to be >> able to do that. But how can the compiler know which functions are safe to >> use and which are out of bound for an actor? > > The design I outline allows you to call it, and punts on the problem of > safety: > https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#global-mutable-state > > <https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#global-mutable-state> > >> Actors shouldn't access the global mutable state and thus should only call >> functions that do not access the global mutable state. We probably need a >> concept of a functions being pure (as in not accessing the global mutable >> state) for that. > > I’m not aware of a practical model to achieve that, but if there were, more > safety would provide more goodness :-) > > >> # About the part "Does a type provide proper value semantics?" >> >> I would argue that this is the wrong question. Most types are a hybrid form >> of value and reference semantics. All you need is to limit what you do to >> what is proper value semantics and forbid the parts that use reference >> semantics. Otherwise you are pessimising the capabilities of the types. >> >> For instance, has Array<UIView> value semantics? > > By the commonly accepted definition, Array<UIView> does not provide value > semantics.
Dave Abrahams and I had an extremely long exchange at one point where he was taking the opposite position (if I understood it correctly). It would be nice to have the Swift community adopt a standard definition of value semantics and document it on swift.org <http://swift.org/>. :) > >> You might be tempted to say that it does not because it contains class >> references, but in reality that depends on what you do with those UIViews. > > An aspect of the type (“does it have value semantics or not”) should not > depend on the clients. By your definition, every type has value semantics if > none of the mutating operations are called :-) > >> If you treat the class references as opaque pointers (never dereferencing >> them), you preserve value semantics. You can count the elements, shuffle >> them, all without dereferencing the UIViews it contains. Value semantics >> only end when you dereference the class references. And even then, there are >> some exceptions. > > I agree with you that the model could permit all values to be sent in actor > messages, but doing so would give up the principle advantages of mutable > state separation. You’d have to do synchronization, you’d have the same bugs > that have always existed, etc. > > -Chris > > > _______________________________________________ > 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
