> On Aug 18, 2017, at 7:19 AM, Michel Fortin <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. > 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
