Sorry for the terse answer, I’ll try to expand a bit on my reasoning here.
In the Swift book, in “Language Reference” -> “Declarations” -> “In-Out Parameters”, it says:
“You can’t pass the same argument to multiple in-out parameters because the order in which the copies are written back is not well defined”.
Now, I am not 100% sure whether &arr and &arr[2] can be considered the same argument, but I would argue that they can because arr contains arr[2].
And because passing the same argument to two inout parameters is not allowed, the compiler can use an optimization like call-by-reference.
Here is an example, where the compiler assumes the arguments are not the same, and therefore uses call-by-reference instead of copy-in-copy-out:
struct S {
var a: Int
}
func foo(inout s: S, _ a: inout Int) {
a += 1
s.a += 1
}
var s = S(a: 0)
foo(&s, &s.a)
print(s) // prints 2
So, to come back to the original example. Here is what I think is happening.
Even though arrays are value types, internally they use a reference-counted buffer. In order to mutate the array, the internal buffer must be uniquely referenced. If it is not, a new identical buffer is created.
So I’m going to follow the life of these internal buffers in the sample code:
var arr = [1,2,3]
// arr.buffer = buffer1 (new buffer)
// buffer1’s reference count: +1
foo(&arr, b: &arr[2])
func foo(inout a: [Int], inout b: Int) {
// buffer1: +1
let acopy = a
// acopy.buffer = a.buffer (which is buffer1)
// buffer1: +2
a = [4, 5, 6]
// a changes, but it has value semantics and a.buffer’s reference count is > 1
// Therefore a new buffer is created.
// a.buffer = buffer2 (new buffer identical to buffer1)
// Now:
// buffer1: +1
// buffer2: +1
print(acopy) // prints buffer1: "[1, 2, 3]"
b = 99 // b points to address in buffer1 because of call-by-reference optimization
// buffer1[2] = 99
print(a) // prints buffer2: "[4, 5, 6]"
print(acopy) // prints buffer1: "[1, 2, 99]"
// Now a is returned -> buffer2 is returned and stays alive
// acopy not returned -> buffer1’s reference count drops to zero -> it is destroyed
}
print(arr) // prints buffer2: "[4, 5, 6]"
I hope this helps and that I haven’t made any mistake 
Loïc
···
On Jun 11, 2016, at 10:52 PM, Loïc Lecrenier via swift-users <swift-users@swift.org> wrote:
Hi,
I think what you said is correct. However, it is not a bug. We can't pass two inout arguments that alias each other because then the behaviour is undefined. It is documented in the Swift book somewhere.
Loïc
Sent from my iPad
On Jun 11, 2016, at 10:36 PM, Jens Alfke via swift-users <swift-users@swift.org> wrote:
On Jun 11, 2016, at 11:57 AM, David Sweeris via swift-users <swift-users@swift.org> wrote:
You can’t pass a `let` as an `inout` argument. I’d guess that’s what’s happening is the `arr[2]` part is creating a temporary var to which the `&` part then provides a reference.
But `arr` is a var, not a let.
`b` is then dutifully modified in the function, but there’s no mechanism for copying it back into `arr` when `foo` returns
No, it gets copied back using subscript assignment. Remember, `inout` isn’t really passing the address of the parameter (although the optimizer may reduce it to that.) It’s literally in-and-out: the caller passes the original value, the function returns the new value, the caller then stores the new value where the old value came from.
I am not a Swift guru, but I think the problem in this example is that there’s a sort of race condition in that last post-return stage: the function has returned new values for both `arr` and arr[2]`, both of which get stored back where they came from, but the ordering is significant because arr[2] will have a different value depending on which of those assignments happens first.
This smells like those C bugs where the result of an expression depends on the order in which subexpressions are evaluated — something like “x = i + (i++)”. The C standard formally declares this as undefined behavior.
The part I’m still confused by is how `acopy` got modified within the `foo` function, since it’s declared as `let`. After staring at this for a while longer, I’m forced to conclude that the compiler decided it could optimize the `b` parameter by actually passing a pointer to the Int and modifying it directly, and that this has the side effect of modifying the Array object that `acopy` is pointing to, even though it’s supposed to be immutable.
In other words, this looks like a compiler bug. I can reproduce it with Swift 2.2 (which is what my `swift` CLI tool says it is, even though I have Xcode 7.3.1 and I thought that was Swift 2.3?)
—Jens
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users