<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=""><div class="">The benefit that standard library containers have over containers from other modules is that they're optimized as if they were part of your own module, so you can get the same thing by including the collection classes in your own executable instead of linking with the module. It's my understanding that the @_transparent attribute could surface to the public side with module format stability.</div><div class=""><br class=""></div><div class="">Either way, the issue of cross-module optimizations is separate from COW mechanics, and it was certainly not my goal to distract anyone from the main topic by including an after-thought reference to an algorithmically impressive package. The important takeaway is that COW semantics don't rely on special features, joined() doesn't have to go out of its way to ensure that new storage isn't allocated, and the one important library feature behind these containers, isKnownUniquelyReferenced, lives in broad daylight.</div><br class=""><div><blockquote type="cite" class=""><div class="">Le 8 août 2017 à 22:56, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Aug 9, 2017 at 1:50 AM, Rob Mayoff <span dir="ltr" class=""><<a href="mailto:mayoff@dqd.com" target="_blank" class="">mayoff@dqd.com</a>></span> wrote:<br class=""><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" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class="gmail-h5">On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users <span dir="ltr" class=""><<a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a>></span> wrote:<br class=""><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" class=""><span class="gmail-m_6345699235369980891gmail-"><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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;" class=""><div class="">Yes, exactly. An Array<T> 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" class="">isKnownUniquelyReference<wbr class="">d</a>. If not, they make a fresh copy before applying the mutating operation.</div><div class=""><br class=""></div><div class="">There's no difference for `let` arrays. Access control is enforced at compile-time through Array'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 class=""><br class=""></div><div class="">There is no secret. Anyone could implement the same thing only using publicly available and documented compiler features. In fact, it's been done already for <a href="https://github.com/lorentey/BTree" target="_blank" class="">some very powerful collections</a>.</div></div></blockquote></div><br class=""></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" class="">Array</span>, down to about <i class="">n</i> = 1,500 items, not <i class="">n</i> = <i class="">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" class="">Array</span> all the way down to <i class="">n</i> = 1.) Red-Black trees are slow when <i class="">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" class="">Array</span> for most reasonable <i class="">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 class=""></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">This seems harsh. I didn't notice Félix making any claims about BTree's performance. The necessary API for implementing COW is indisputably public and documented:</div><div class=""><br class=""></div><div class=""><a href="https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced" target="_blank" class="">https://developer.apple.com/<wbr class="">documentation/swift/2429905-<wbr class="">isknownuniquelyreferenced</a><br class=""></div><div class=""><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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 class="">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 class=""></div></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>