<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 11, 2016, at 3:36 PM, Jens Alfke <<a href="mailto:jens@mooseyard.com" class="">jens@mooseyard.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 11, 2016, at 11:57 AM, David Sweeris via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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. </span></div></blockquote><div class=""><br class=""></div><div class="">But `arr` is a var, not a let.</div></div></div></div></blockquote><div><br class=""></div>I know. You’d said that you "can't believe a let variable gets changed”. I was just pointing out that you’re correct, in that the compiler will complain if you try to pass one as an in-out argument.<br class=""><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">`b` is then dutifully modified in the function, but there’s no mechanism for copying it back into `arr` when `foo` returns</span></div></blockquote><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>I don’t think it can… My recollection is that in Swift the subscript operator (`arr[2]` in this case) can refer to the setter xor the getter, but <i class="">not both within the same statement</i>. If that’s correct, for there to be a value to pass to the function, `arr[2]` must be referring to the getter version, which means that there’s no setter to update the value when `foo` returns.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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 <i class="">the ordering is significant</i> because arr[2] will have a different value depending on which of those assignments happens first.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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 <i class="">could</i> 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.</div><div class=""><br class=""></div><div class="">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?)</div></div></div></blockquote></div><br class=""><div class="">Ah… I see what you mean about a `let` getting modified now… My mistake, I thought you were wondering why `arr` wasn’t `[4, 5, 99]` after foo returned. Yeah, I’m not sure about what’s happening within `foo`... Maybe someone who knows more will come along and provide an explanation, but at the moment I’m inclined to agree — both that you’ve found a bug, and with your guess and to how it’s happening. </div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></body></html>