Why doesn't the example violate SE-0176 (Exclusive Access to Memory)?

[rayx (Huan Xiong)]

@John_McCall

You can think of that as “copy-in, copy-out” if you like, pretending that the inout parameter is actually a variable that gets initialized. It gives a very intuitive explanation of what happens with computed get/set storage. On the other hand, it’s misleading when the storage is actually stored, because it suggests that there are real copies that the compiler has to work to eliminate. And in some ways it’s especially misleading with exclusivity, because you might think that it ought to turn into one instantaneous read later followed by an instantaneous write, as opposed to a prolonged access.

Hi John, I find an example where the "copy-in, copy-out" approach can explain why it works but the "prolonged access" approach you recommended seems to suggest it shouldn't.

struct Foo {
    var x: Int = 0

    func modifyX(_ foo: inout Foo) {
        foo.x = 1
        print("In modifyX(): \(self.x)")
        print("In modifyX(): \(foo.x)")
    }
}

var foo = Foo()
foo.modifyX(&foo)
print("After modifyX(): \(foo.x)")

// Output:
// In modifyX(): 0
// In modifyX(): 1
// After modifyX(): 1

The modifyX() has read access to the globle variable foo through the implicit immutable self. It also has write access to the global variable foo through the inout foo parameter. If I understand it correctly, that's an overlap and the issue should be caught at runtime, right? But the code actually runs well.