<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 18, 2017, at 2:15 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 18, 2017, at 7:19 AM, Michel Fortin <<a href="mailto:michel.fortin@michelf.ca" class="">michel.fortin@michelf.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Great writeup. Here's a few comments about the manifesto, actors and value semantics specifically.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""># About actors and data isolation</div><div class=""><br class=""></div><div class="">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?</div></div></div></blockquote><div class=""><br class=""></div><div class="">The design I outline allows you to call it, and punts on the problem of safety:</div><div class=""><a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#global-mutable-state" class="">https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#global-mutable-state</a></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I’m not aware of a practical model to achieve that, but if there were, more safety would provide more goodness :-)</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""># About the part "Does a type provide proper value semantics?"</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">For instance, has Array<UIView> value semantics? </div></div></div></blockquote><div class=""><br class=""></div><div class="">By the commonly accepted definition, Array<UIView> does not provide value semantics.</div></div></div></div></blockquote><div><br class=""></div><div>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 <a href="http://swift.org" class="">swift.org</a>. :)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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 :-)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> 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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>