> 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]
>> <mailto:[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
