[swift-evolution] [Concurrency] async/await + actors

[Matthew Johnson]

> On Aug 18, 2017, at 2:15 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Aug 18, 2017, at 7:19 AM, Michel Fortin <michel.fortin at michelf.ca <mailto:michel.fortin at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170818/5fa9daea/attachment-0001.html>