[swift-users] inout params seem to have undefined behavior

zh ao owenzx at gmail.com
Mon Jun 13 23:00:37 CDT 2016


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 at swift.org> wrote:

>
> On Jun 13, 2016, at 1:43 PM, Joe Groff <jgroff at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160614/6718a67e/attachment.html>


More information about the swift-users mailing list