<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Since your backing buffer is copy-on-write, you can do the in-place mutation optimization in your immutable implementations, something like this:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">class C {</div><div class="">&nbsp; var value: Int</div><div class="">&nbsp; init(value: Int) { self.value = value }</div><div class="">}</div><div class=""><br class=""></div><div class="">struct S { var c: C }</div><div class=""><br class=""></div><div class="">func addInts(x: S, y: S) -&gt; S {</div><div class="">&nbsp; var tmp = x</div><div class="">&nbsp; // Don't use x after this point so that it gets forwarded into tmp</div><div class="">&nbsp; if isKnownUniquelyReferenced(&amp;tmp.c) {</div><div class="">&nbsp; &nbsp; tmp.c.value += y.c.value</div><div class="">&nbsp; &nbsp; return tmp</div><div class="">&nbsp; } else {</div><div class="">&nbsp; &nbsp; return S(c: C(value: tmp.c.value + y.c.value))</div><div class="">&nbsp; }</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">which should let you get similar efficiency to the mutating formulation while using semantically immutable values.</div><div class=""><br class=""></div><div class="">-Joe</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">On Aug 5, 2016, at 2:35 PM, Fritz Anderson via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:<br class=""><br class="">Swift 3 as of Xcode 8.0b4<br class=""><br class="">TL;DR: I have a struct value type backed by a copy-on-write mutable buffer. You use it to perform arithmetic on the buffers. The most expressive way to do this&nbsp;efficiently is to chain the arithmetic operators so each mutates the same buffer. Swift does not like to chain mutating operators — it treats the result of each step as&nbsp;immutable, so you can’t continue the chain. I can’t argue; the syntax apparently can't express anything else.<br class=""><br class="">All the alternatives I see are ugly-to-dangerous.<br class=""><br class="">Have I missed something, I hope? Please make a fool of me.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>— F<br class=""><br class="">The details of my use case or implementation are off-topic; even if mine are ill-considered, surely apt ones exist. Unless you can demonstrate there are none.<br class=""><br class="">The&nbsp;vDSP_*&nbsp;functions in Apple’s Accelerate framework are declared in C to operate on naked float or double pointers. I decided to represent such&nbsp;Float&nbsp;buffers in&nbsp;Swift by a struct (call it&nbsp;ManagedFloatBuffer) containing a reference to a&nbsp;FloatBuffer, which is a final specialization of class&nbsp;ManagedBuffer&lt;Int, Float&gt;.<br class=""><br class="">(The names are a work-in-progress. Just remember:&nbsp;ManagedFloatBuffer&nbsp;is a value type that can copy-on-write to a reference to&nbsp;FloatBuffer, a backing store&nbsp;for a bunch of&nbsp;Floats.)<br class=""><br class="">The nonmutating funcs:<br class=""><br class="">&nbsp; &nbsp; func subtract(_ other: ManagedFloatBuffer) -&gt; ManagedFloatBuffer<br class="">&nbsp; &nbsp; func subtract(_ scalar: Float) -&gt; ManagedFloatBuffer<br class=""><br class="">are straightforward. They return new&nbsp;ManagedFloatBuffer&nbsp;values. You can chain further calls to simplify a complex calculation that is neither intricate nor tied up in&nbsp;temporaries:<br class=""><br class="">&nbsp; &nbsp; let sum²OfResiduals = speeds<br class="">&nbsp; &nbsp; &nbsp; &nbsp; .subtract(cameraSpeed.mean)<br class="">&nbsp; &nbsp; &nbsp; &nbsp; .multiply(feetToMeters)<br class="">&nbsp; &nbsp; &nbsp; &nbsp; .sumOfSquares<br class=""><br class="">Great. And vDSP gets you about a 40% boost. (The compiler itself seems to do a pretty good job of auto-vectorizing; the unoptimized code is a couple of orders of&nbsp;magnitude slower.) But as you chain the immutables, you generate new&nbsp;FloatBuffers to hold the intermediate results. For long chains, you end up allocating new&nbsp;buffers (which turns out to be expensive on the time scale of vectorized math) and copying large buffers into them that you are about to discard. I want my Swift code&nbsp;to be as performant as C, but safer and more expressive.<br class=""><br class="">So how about some mutating functions to change a&nbsp;ManagedFloatBuffer’s bytes in-place (copying-on-write as needed so you can preserve intermediate values)?<br class=""><br class="">&nbsp; &nbsp; mutating func reduce(by other: ManagedFloatBuffer) -&gt; ManagedFloatBuffer<br class="">&nbsp; &nbsp; mutating func reduce(by scalar: Float) -&gt; ManagedFloatBuffer<br class=""><br class="">These return&nbsp;self, because I’d hoped I could chain operators as I did with the non-mutating versions.<br class=""><br class="">The compiler doesn’t like this. It says&nbsp;reduce(by:)&nbsp;returns an immutable value, so you can’t chain mutating functions.<br class=""><br class="">(I can see an issue in that when the first func's&nbsp;self&nbsp;is copied as the return value that is used as the second func’s&nbsp;self, &nbsp;that could make two surviving references to&nbsp;the same buffer, so a buffer copy would happen when you mutate the second func’s&nbsp;self&nbsp;anyway. I’m not sure the compiler&nbsp;has&nbsp;to do that, but I can see how it might&nbsp;be hard to account for otherwise. Hey, it’s a tail call, right? SMOP, not source-breaking at all.)<br class=""><br class="">StackOverflow invites me to eat cake: Make the mutable operand inout to funcs I call one by one. Something like:<br class=""><br class="">&nbsp; &nbsp; multiply(perspectiveCorrections, into: &amp;pixelXes)<br class="">&nbsp; &nbsp; sin(of: &amp;pixelXes)<br class="">&nbsp; &nbsp; multiply(pixelXes, into: &amp;speeds)<br class="">&nbsp; &nbsp; multiply(feetToMeters, into: &amp;speeds)<br class="">&nbsp; &nbsp; subtract(cameraSpeed.mean, from: &amp;speeds)<br class="">&nbsp; &nbsp; let sumSquaredOfResiduals = speeds.sumOfSquares<br class=""><br class="">&nbsp; &nbsp; // grodiness deliberately enhanced for illustration<br class=""><br class="">I’d rather not. The thing to be calculated is named at the bottom of the paragraph. The intermediate steps must preserve names that change meaning line-by-line. You&nbsp;have to study the code to recognize it as a single arithmetic expression.<br class=""><br class="">And by the by, if a vector operand is itself the result of a mutating operation, the dependency graph becomes a nightmare to read — I can’t be sure the illustration&nbsp;even expresses a plausible calculation.<br class=""><br class="">Thinking up more reasons to hate this solution is a fun parlor game you and your family can play at home.<br class=""><br class="">Strictly speaking, the compiler is right: I don’t see any language construct that expresses that a returned value type that may be mutated by a chained func. Am I&nbsp;correct?<br class=""><br class="">I’m not at all happy with turning&nbsp;ManagedFloatBuffer&nbsp;into a class. Intuitively, this is a value type. Passing a packet of&nbsp;Floats into a func (or into another thread, as&nbsp;one does with math) and finding your&nbsp;Floats had changed in the mean time is… surprising.<br class=""><br class="">I’m not optimistic, but I have to ask: Is there a way to do this — to take mutability down an operator chain?<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>— F<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></blockquote><br class=""></div></body></html>