On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution < swift-evolut...@swift.org> wrote:
> 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 isKnownUniquelyReferenced > <https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced>. > If not, they make a fresh copy before applying the mutating operation. > > 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. > > 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 some very powerful collections > <https://github.com/lorentey/BTree>. > 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 Array, down to about *n* = 1,500 items, not *n* = *100,000* items as it claims. (Actually, heap allocators these days are good enough that performance is on par with Array all the way down to *n* = 1.) Red-Black trees are slow when *distributed* as packages because of the crossmodule optimization boundary. (This also means the BTree module is much slower than Array for most reasonable *n*.) 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.
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
