[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