<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m sending directly to those who took time over my question, because, per Michael’s request, I have a minimal case to attach. Phrases in <b class="">boldface</b> are for skimmability, not shouting. <div class=""><br class=""></div><div class="">Strip out my use case (I’m encouraged that Dave recapitulated exactly what I was asking about). My remaining question is: <b class="">How do you safely reuse a class reference as the backing store for a struct?</b> Yes, it’s done all the time, but the trick requirement is that I want to chain the funcs that do it; chained value returns are immutable; and as far as I could tell, you can’t get CoW-safe reuse without mutating <font face="Input Mono" size="2" class="">self</font>. The result is that you are forced to make expensive copies of the backing store every time. Joe’s solution looked promising in that it purported to pass the CoW buffer (if possible) out of the func after doing all the mutation internally.</div><div class=""><br class=""></div><div class=""><b class="">I couldn’t figure out how the answer Joe gave could work</b>: His code duplicates the struct’s original reference into a copy of the struct, after which he expects the runtime to report (when possible) that no such duplicate exists. I asked how this could be, as my attempt to replicate in a playground showed the reference was <i class="">never</i> found unique — which is what I had intuitively expected.</div><div class=""><br class=""></div><div class="">He says this fundamental design pattern in Swift works only if you change the semantics of the language by turning on the optimizer. (Sorry to be all Asperger's about it, but nobody corrected me the first time I put it this way.)</div><div class=""><br class=""></div><div class="">I have many, many questions, I might even hazard objections, but they’re moot: <b class="">Optimized or not, that code <i class="">never</i> reuses the backing object.</b> </div><div class=""><br class=""></div><div class="">The attached project was built with Xcode 8.0b5. It uses Joe’s code (except I still must use <span style="color: rgb(19, 145, 162); font-family: 'Input Mono'; font-size: 13px; font-variant-ligatures: no-common-ligatures;" class="">isUniquelyReferencedNonObjC</span><span style="font-family: 'Input Mono'; font-size: 13px; font-variant-ligatures: no-common-ligatures;" class="">(_:</span><span style="font-family: 'Input Mono'; font-size: 13px; font-variant-ligatures: no-common-ligatures;" class="">)</span>). I run <span style="color: rgb(68, 125, 133); font-family: 'Input Mono'; font-size: 13px;" class="">addInts</span><span style="font-family: 'Input Mono'; font-size: 13px;" class="">(x:, y:)</span> and check two ways whether the reference was found unique. Same result, optimized or not.</div><div class=""><br class=""></div><div class="">It occurred to me that the globals <span style="font-family: 'Input Mono'; font-size: 13px;" class="">s_x</span> and <span style="font-family: 'Input Mono'; font-size: 13px;" class="">s_y</span> might bump the reference count. I removed them and used this instead:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 13px; line-height: normal; font-family: 'Input Mono';" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #0329d9" class="">let</span><span style="font-variant-ligatures: no-common-ligatures" class=""> s_result = </span><span style="font-variant-ligatures: no-common-ligatures; color: #447d85" class="">addInts</span><span style="font-variant-ligatures: no-common-ligatures" class="">(x: </span><span style="font-variant-ligatures: no-common-ligatures; color: #5b9ea9" class="">S</span><span style="font-variant-ligatures: no-common-ligatures" class="">(c: </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">C</span><span style="font-variant-ligatures: no-common-ligatures" class="">(value: </span><span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">99</span><span style="font-variant-ligatures: no-common-ligatures" class="">)), y: </span><span style="font-variant-ligatures: no-common-ligatures; color: #5b9ea9" class="">S</span><span style="font-variant-ligatures: no-common-ligatures" class="">(c: </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">C</span><span style="font-variant-ligatures: no-common-ligatures" class="">(value: </span><span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">-98</span><span style="font-variant-ligatures: no-common-ligatures" class="">)))</span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><div class="">Still no unique references.</div><div class=""><br class=""></div><div class="">I recognize I am taking up a lot of god time mere days before a major release, when <b class="">the likeliest outcome is that I’m a jackass</b>. My concern runs deeper than what’s in this message, but I shouldn't muddy the waters. Those deeper things can go back to the public once I understand the issue better (or you boot me back).</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class=""><b class="">Context (supplementary, no need to spend time)</b></div><div class=""><br class=""></div><div class="">If seeing what I’m trying to do helps, I’ve attached my attempt. I’m sure there are defects in API style, safety, and correctness. I’d have done more if I hadn’t suspended the project over this issue. Class <font face="Input Mono" size="2" class="">FloatBuffer</font> is the backing store; <font face="Input Mono" size="2" class="">ManagedFloatBuffer</font> is the wrapper class that does all the operations. None of the operations are declared <font face="Input Mono" size="2" class="">mutating</font>. </div><div class=""><br class=""></div><div class="">Anything that calls <font face="Input Mono" size="2" class="">(unary|binary)Operator</font> returns a fresh <font face="Input Mono" size="2" class="">ManagedFloatBuffer</font> every time; structs and their buffers are created and initialized every time — <i class="">intentionally.</i> It seems to work well under gentle use.</div><div class=""><br class=""></div><div class="">Callers of <font face="Input Mono" size="2" class="">mutabilityWrapper</font> preserve the receiver’s backing buffer whenever possible and mutate it in-place. Those funcs always return <font face="Input Mono" size="2" class="">self</font>. These might be a big win; I can’t tell because I’ve never been able to get unique references. Because there’s an allocation (possibly initialization) every time, they are no better than the <span style="font-family: 'Input Mono'; font-size: small;" class="">(unary|binary)Operator</span> funcs. <font face="Input Mono" size="2" class="">malloc</font> and friends take up a significant amount of time on the scale of vector math.</div><div class=""><br class=""></div><div class="">Both flavors can cascade; the only problem is that the “in-place” methods don’t live up to the name.</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=""></div></div></body></html>