> On Aug 18, 2017, at 9:19 AM, Michel Fortin via swift-evolution > <swift-evolution@swift.org> 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? > > 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. > > > # 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? 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. 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 suggested a little while ago on this list some principles based on this > that would allow for the compiler to enforce value semantics with a `pure` > attribute and I'm currently working on a draft proposal. In essence this > proposal will have pure functions guaranteeing value semantics and no access > to the global state, and a correct implementation for copy-on-write types. I > think this would be useful for actors.
It’s great to hear that you’re returning to the topic of pure functions Michel! Please let me know if there is anything I can do to help. > > > >> Le 17 août 2017 à 18:24, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> Hi all, >> >> As Ted mentioned in his email, it is great to finally kick off discussions >> for what concurrency should look like in Swift. This will surely be an epic >> multi-year journey, but it is more important to find the right design than >> to get there fast. >> >> I’ve been advocating for a specific model involving async/await and actors >> for many years now. Handwaving only goes so far, so some folks asked me to >> write them down to make the discussion more helpful and concrete. While I >> hope these ideas help push the discussion on concurrency forward, this isn’t >> in any way meant to cut off other directions: in fact I hope it helps give >> proponents of other designs a model to follow: a discussion giving extensive >> rationale, combined with the long term story arc to show that the features >> fit together. >> >> Anyway, here is the document, I hope it is useful, and I’d love to hear >> comments and suggestions for improvement: >> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 >> <https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782> >> >> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > -- > Michel Fortin > https://michelf.ca <https://michelf.ca/> > _______________________________________________ > 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
