Exactly. Sent from my moss-covered three-handled family gradunza
> On Feb 24, 2017, at 9:49 AM, David Sweeris <[email protected]> wrote: > > >>> On Feb 23, 2017, at 4:04 PM, Ted F.A. van Gaalen via swift-evolution >>> <[email protected]> wrote: >>> >>> >> >>> On 23 Feb 2017, at 02:24, Dave Abrahams <[email protected]> wrote: >>> >>> Equally a non-starter. All known threadsafe schemes that require caches to >>> be updated upon non-mutating operations have horrible performance issues, >>> and further this would penalize all string code by reserving space for the >>> cache and filling it even for the vast majority of operations that don't >>> require random access. >> Well, maybe “caching” is not the right description for what I've suggested. >> It is more like: >> let all strings be stored as they are now, but as soon as you want to work >> with >> random accessing parts of a string just “lift the string out of normal >> optimised string storage” >> and then add (temporarily) a Character array so one can work with this >> array directly ” >> which implies that all other strings remain as they are. ergo: efficiency >> is only reduced for the “elevated” strings, >> Using e.g. str.freeSpace(), if necessary, would then place the String back >> in its normal storage domain, thereby disposing the Character array >> associated with it. > > Wouldn’t that turn simple character access into a mutating function? > > - Dave Sweeris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
