<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users <span dir="ltr">&lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Yes, exactly. An Array&lt;T&gt; is a struct wrapper for a reference type representing storage. Mutating functions first check if they own the only reference to the storage using <a href="https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced" target="_blank">isKnownUniquelyReference<wbr>d</a>. If not, they make a fresh copy before applying the mutating operation.</div><div><br></div><div>There&#39;s no difference for `let` arrays. Access control is enforced at compile-time through Array&#39;s design: the compiler will prevent you from calling `mutating` functions on `let` structs, and Array is careful to not expose functionality that could modify its storage outside of `mutating` functions.</div><div><br></div><div>There is no secret. Anyone could implement the same thing only using publicly available and documented compiler features. In fact, it&#39;s been done already for <a href="https://github.com/lorentey/BTree" target="_blank">some very powerful collections</a>.</div></div></blockquote></div><br></div></span><div class="gmail_extra">This isn’t entirely true. That BTree module readme seems to contain a lot of unsubstantiated hyperbole. It’s possible to implement a classic red-black tree in Swift that performs better than a sorted <span style="font-family:monospace,monospace">Array</span>, down to about <i>n</i> = 1,500 items, not <i>n</i> = <i>100,000</i> items as it claims. (Actually, heap allocators these days are good enough that performance is on par with <span style="font-family:monospace,monospace">Array</span> all the way down to <i>n</i> = 1.) Red-Black trees are slow when <i>distributed</i> as packages because of the crossmodule optimization boundary. (This also means the BTree module is much slower than <span style="font-family:monospace,monospace">Array</span> for most reasonable <i>n</i>.) It’s possible to write modules using compiler attributes that mitigate this slowdown (reclaiming over 50% of lost performance) but it’s hacky and forces you to design your libraries like the standard library (meaning: ugly underscored properties everywhere and everything is public). And these features aren’t “publicly available” or documented at all. <br></div></div></blockquote><div><br></div><div>This seems harsh. I didn&#39;t notice Félix making any claims about BTree&#39;s performance. The necessary API for implementing COW is indisputably public and documented:</div><div><br></div><div><a href="https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced">https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced</a><br></div><div><br></div></div></div></div>