[swift-users] Law of Exclusivity runtime false positive?

Andrew Trick atrick at apple.com
Sun Jul 30 17:35:34 CDT 2017


> On Jul 30, 2017, at 5:11 AM, David Hart via swift-users <swift-users at swift.org> wrote:
> 
>> 
>> On 28 Jul 2017, at 18:55, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>>> 
>>> On Jul 28, 2017, at 12:06 AM, David Hart via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>> 
>>> Hello,
>>> 
>>> Indeed, I had reduced the code too much. John McCall was kind enough to have a look and here’s the offending code:
>>> 
>>> func layoutHorizontally(leftRect: inout CGRect, rightRect: inout CGRect) {
>>>     let totalWidth = imageRect.size.width + titleRect.size.width + contentSpacing
>>>     rightRect.origin.x = leftRect.maxX + contentSpacing
>>> }
>>> 
>>> The problem is that imageRect and titleRect are referenced both directly and in the inout parameters.
>>> 
>>> But there’s something I’m not understanding. I went back to the ownership manifesto and re-read the law of exclusivity to make sure I understand it:
>>> 
>>> If a storage reference expression evaluates to a storage reference that is implemented by a variable, then the formal access duration of that access may not overlap the formal access duration of any other access to the same variable unless both accesses are reads.
>>> 
>>> So I tried to write a test to trigger the runtime error, but was unsuccessful:
>>> 
>>> class MyClass {
>>>     var p: CGRect = .zero
>>> }
>>> 
>>> func trigger(a: MyClass, b: MyClass) {
>>>     a.p = b.p
>>> }
>>> 
>>> let m = MyClass()
>>> trigger(a: m, b: m)
>>> 
>>> Here, a storage reference expression (a.p) evaluates to a storage reference that is implemented by a variable (the p property of an instance m of MyClass) and its formal access duration (the trigger function) overlaps the formal access duration of another access to the same variable (through the b.p storage reference expression) and both accesses are not reads (a.p is on the LHS of an assignment).
>>> 
>>> Why does this not trigger the Law of Exclusivity?
>> 
>> `b.p` is loaded before `a.p` is written to, so the accesses do not overlap even when a === b. Something like swap(&a.p, &b.p) (using the Swift 3 global definition of 'swap') would trigger an exclusivity trap when a === b, since the access to storage passed as an inout argument needs to last for the duration of the call.
> 
> Thanks for the explanation! It’s starting to make sense :) Is it possible to trigger the exclusivity trap without an inout argument?
> 
>> -Joe


Users are probably more likely to run into problems with mutating methods, which are implicitly `inout`: 

struct S {
  var x = 1

  mutating func updateX(_ getOtherS: ()->S) {
    x += getOtherS().x
  }
}

class C {
  var s = S()
}

let c = C()
c.s.updateX( { c.s } )

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170730/a1c9f396/attachment.html>


More information about the swift-users mailing list