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. > Le 17 août 2017 à 18:24, Chris Lattner via swift-evolution > <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 > > -Chris > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution -- Michel Fortin https://michelf.ca
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
