[swift-users] non-mutating func that still mutates a struct, compiler not aware

[Raphael Sebbe]

Do you see a reason why the copy isn't happening in this specific case? Is
it a bug, or a mistake in my code?

Thank you,

Raphael

On Thu, Aug 4, 2016 at 4:18 PM Brent Royal-Gordon <brent at architechies.com>
wrote:

> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160805/0c1995d1/attachment.html>