According to the latest Swift 3 docs “As an optimization, when the argument is a value stored at a physical address in memory, the same memory location is used both inside and outside the function body. The optimized behavior is known as call by reference; it satisfies all of the requirements of the copy-in copy-out model while removing the overhead of copying. Write your code using the model given by copy-in copy-out, without depending on the call-by-reference optimization, so that it behaves correctly with or without the optimization.”
摘录来自: Apple Inc. “The Swift Programming Language (Swift 3)”。 iBooks. So the behavior is because of the optimization, which should not rely on. Zhaoxin On Tue, Jun 14, 2016 at 5:12 AM, Jens Alfke via swift-users < swift-users@swift.org> wrote: > > On Jun 13, 2016, at 1:43 PM, Joe Groff <jgr...@apple.com> wrote: > > I see, missed that part. That's a bug—`acopy` should remain a distinct > copy of `a`. > > > I’m guessing that when `a` is copied into `acopy`, the same array contents > are shared between them, then when `a` is mutated it gets a new copy of the > contents. Then the assignment to `b` writes into the original array > contents now held by `acopy`. > > Still seems like it’s caused by having aliased `inout` variables, but the > effect is nastier. I can imagine horrible bugs where `acopy` gets passed > around somewhere else and then changes, breaking the something-else that’s > holding it. It could be hard to track that back to its original cause, > especially if there are two different codebases involved. > > —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
