<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 9, 2017 at 1:50 AM, Rob Mayoff <span dir="ltr">&lt;<a href="mailto:mayoff@dqd.com" target="_blank">mayoff@dqd.com</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"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-h5">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-m_6345699235369980891gmail-"><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="overflow-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></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" target="_blank">https://developer.apple.com/<wbr>documentation/swift/2429905-<wbr>isknownuniquelyreferenced</a><br></div><div><br></div></div></div></div></blockquote><div><br></div><div>I really didn’t mean it to be harsh (sorry if it sounded that way 🙁), it’s just that people tend to be overly optimistic about the performance that can be achieved with custom Collection packages. It’s true that you can imitate the <i>functionality</i> of stdlib Collection types with public and documented Swift features, but such custom Collections (when distributed as packages) are almost never effective at improving an application’s performance due to the huge constant factor of cross module calls, unless the library author was willing to make use of undocumented compiler features.<br></div></div><br></div></div>