[swift-users] non-mutating func that still mutates a struct, compiler not aware
Brent Royal-Gordon
brent at architechies.com
Thu Aug 4 09:18:15 CDT 2016
> On Aug 4, 2016, at 1:25 AM, Raphael Sebbe via swift-users <swift-users at swift.org> wrote:
>
> My understanding is that the compiler doesn't make a real copy in the acopy = self instruction, and then provides that contents to the mx_gels_ function which modifies the memory contents.
>
>
> public func solve(rhs b: Matrix<T>) -> Matrix<T>? {
> // ...
> var acopy = self
> // ...
>
> T.mx_gels_(&trans, &m, &n, &nrhs, UnsafeMutablePointer<T>(acopy.values), &lda, UnsafeMutablePointer<T>(x.values), &ldb, UnsafeMutablePointer<T>(workspace), &lwork, &status);
>
> // ...
> }
>
>
> Is this expected? I mean, I can force a real copy of course, but value semantics would suggest the code above is correct and wouldn't need that. Shouldn't the cast trigger the copy somehow? Or is there a better way of expressing this operation? Thx.
The `acopy = self` line only copies the reference to the internal buffer. However, converting the array into a pointer will—or at least, if done properly, *should*—force the array to create and switch to using a unique copy of its buffer in preparation for writes through the UnsafeMutablePointer. I believe that happens here: <https://github.com/apple/swift/blob/master/stdlib/public/core/Pointer.swift#L79>
(I say "should" because I'm not sure you're actually creating those pointers correctly. I believe you ought to be able to just say `&acopy.values` and `&x.values`, and that should be a more reliable way to do it.)
--
Brent Royal-Gordon
Architechies
More information about the swift-users
mailing list