<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Swift 3 as of Xcode 8.0b4<div class=""><br class=""></div><div class=""><b class="">TL;DR</b>: 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 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 immutable, so you can’t continue the chain. I can’t argue; the syntax apparently can't express anything else.</div><div class=""><br class=""></div><div class="">All the alternatives I see are ugly-to-dangerous.</div><div class=""><br class=""></div><div class="">Have I missed something, I hope? Please make a fool of me.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>— F</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div 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.</div></blockquote><div class=""><br class=""></div><div class="">The <font face="Menlo" class=""><span style="font-size: 12px;" class="">vDSP_*</span></font> functions in Apple’s Accelerate framework are declared in C to operate on naked float or double pointers. I decided to represent such <font face="Menlo" class=""><span style="font-size: 12px;" class="">Float</span></font> buffers in Swift by a struct (call it <font face="Menlo" class=""><span style="font-size: 12px;" class="">ManagedFloatBuffer</span></font>) containing a reference to a <font face="Menlo" class=""><span style="font-size: 12px;" class="">FloatBuffer</span></font>, which is a final specialization of class <font face="Menlo" class=""><span style="font-size: 12px;" class="">ManagedBuffer<Int, Float></span></font>.</div><div class=""><br class=""></div><div class="">(The names are a work-in-progress. Just remember: <font face="Menlo" class=""><span style="font-size: 12px;" class="">ManagedFloatBuffer</span></font> is a value type that can copy-on-write to a reference to <font face="Menlo" class=""><span style="font-size: 12px;" class="">FloatBuffer</span></font>, a backing store for a bunch of <font face="Menlo" class=""><span style="font-size: 12px;" class="">Float</span></font>s.)</div><div class=""><br class=""></div><div class="">The nonmutating funcs:</div><div class=""><br class=""></div><div class=""><span style="font-size: 12px;" class=""><font face="Menlo" class=""> func subtract(_ other: ManagedFloatBuffer) -> ManagedFloatBuffer</font></span></div><div class=""><span style="font-size: 12px;" class=""><font face="Menlo" class=""> func subtract(_ scalar: Float) -> ManagedFloatBuffer<br class=""></font></span><br class=""></div><div class="">are straightforward. They return new <font face="Menlo" class=""><span style="font-size: 12px;" class="">ManagedFloatBuffer</span></font> values. You can chain further calls to simplify a complex calculation that is neither intricate nor tied up in temporaries:</div><div class=""><br class=""></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> let sum²OfResiduals = speeds</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> .subtract(cameraSpeed.mean)</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> .multiply(feetToMeters)</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> .sumOfSquares</font></div><div class=""><br class=""></div><div 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 magnitude slower.) But as you chain the immutables, you generate new <font face="Menlo" class=""><span style="font-size: 12px;" class="">FloatBuffer</span></font>s to hold the intermediate results. For long chains, you end up allocating new 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 to be as performant as C, but safer and more expressive.</div><div class=""><br class=""></div><div class="">So how about some mutating functions to change a <font face="Menlo" class=""><span style="font-size: 12px;" class="">ManagedFloatBuffer</span></font>’s bytes in-place (copying-on-write as needed so you can preserve intermediate values)?</div><div class=""><br class=""></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> mutating func reduce(by other: ManagedFloatBuffer) -> ManagedFloatBuffer</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> mutating func reduce(by scalar: Float) -> ManagedFloatBuffer</font></div><div class=""><br class=""></div><div class="">These return <font face="Menlo" class=""><span style="font-size: 12px;" class="">self</span></font>, because I’d hoped I could chain operators as I did with the non-mutating versions.</div><div class=""><br class=""></div><div class="">The compiler doesn’t like this. It says <font face="Menlo" class=""><span style="font-size: 12px;" class="">reduce(by:)</span></font> returns an immutable value, so you can’t chain mutating functions.</div><div class=""><br class=""></div><div class=""><div class="">(I can see an issue in that when the first func's <font face="Menlo" class=""><span style="font-size: 12px;" class="">self</span></font> is copied as the return value that is used as the second func’s <font face="Menlo" class=""><span style="font-size: 12px;" class="">self</span></font>, that could make two surviving references to the same buffer, so a buffer copy would happen when you mutate the second func’s <font face="Menlo" class=""><span style="font-size: 12px;" class="">self</span></font> anyway. I’m not sure the compiler <i class="">has</i> to do that, but I can see how it might be hard to account for otherwise. Hey, it’s a tail call, right? SMOP, not source-breaking at all.)</div></div><div class=""><br class=""></div><div class="">StackOverflow invites me to eat cake: Make the mutable operand inout to funcs I call one by one. Something like:</div><div class=""><br class=""></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> multiply(perspectiveCorrections, into: &pixelXes)</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> sin(of: &pixelXes)</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> multiply(pixelXes, into: &speeds)</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> multiply(feetToMeters, into: &speeds)</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> subtract(cameraSpeed.mean, from: &speeds)</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> let sumSquaredOfResiduals = speeds.sumOfSquares</font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""><br class=""></font></div><div class=""><font face="Menlo" style="font-size: 12px;" class=""> // grodiness deliberately enhanced for illustration</font></div><div class=""><br class=""></div><div 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 have to study the code to recognize it as a single arithmetic expression.</div><div class=""><br class=""></div><div 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 even expresses a plausible calculation.</div><div class=""><br class=""></div><div class="">Thinking up more reasons to hate this solution is a fun parlor game you and your family can play at home.</div><div class=""><br class=""></div><div 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 correct?</div><div class=""><br class=""></div><div class="">I’m not at all happy with turning <font face="Menlo" class=""><span style="font-size: 12px;" class="">ManagedFloatBuffer</span></font> into a class. Intuitively, this is a value type. Passing a packet of <font face="Menlo" class=""><span style="font-size: 12px;" class="">Float</span></font>s into a func (or into another thread, as one does with math) and finding your <font face="Menlo" class=""><span style="font-size: 12px;" class="">Float</span></font>s had changed in the mean time is… surprising.</div><div class=""><br class=""></div><div class="">I’m not optimistic, but I have to ask: Is there a way to do this — to take mutability down an operator chain?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>— F</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>