> On Jun 11, 2016, at 3:36 PM, Jens Alfke <j...@mooseyard.com> wrote:
>
>
>> On Jun 11, 2016, at 11:57 AM, David Sweeris via swift-users
>> <swift-users@swift.org <mailto: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.
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.
>> `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 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 not both
within the same statement. 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.
> 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?)
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.
- Dave Sweeris
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
