[swift-evolution] Strings in Swift 4
dabrahams at apple.com
Mon Feb 6 16:25:48 CST 2017
on Mon Feb 06 2017, David Waite <david-AT-alkaline-solutions.com> wrote:
>> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org>
>> Hi Dave,
>> Oops! yes, you’re right!
>> I did read again more thoroughly about Unicode
>> and how Unicode is handled within Swift...
>> -should have done that before I write something- sorry.
>> How about this solution: (if I am not making other omissions in my thinking again)
>> -Store the string as a collection of fixed-width 32 bit UTF-32 characters anyway.
>> -however, if the Unicode character is a grapheme cluster (2..n Unicode characters),then
>> store a pointer to a hidden child string containing the actual grapheme cluster, like so:
>> 1: [UTF32, UTF32, UTF32, 1pointer, UTF32, UTF32, 1pointer, UTF32, UTF32]
>> | |
>> 2: [UTF32, UTF32] [UTF32, UTF32, UTF32, ...]
>> whereby (1) is aString as seen by the programmer.
>> and (2) are hidden child strings, each containing a grapheme cluster.
> The random access would require a uniform layout, so a pointer and
> scalar would need to be the same size. The above would work with a 32
> bit platform with a tagged pointer, but would require a 64-bit slot
> for pointers on 64-bit systems like macOS and iOS.
It would also make String not efficiently interoperable with almost any
other system that processes strings including Foundation and ICU.
> Today when I need to do random access into a string, I convert it to
> an Array<Character>. Hardly efficient memory-wise, but efficient
> enough for random access.
I'd be willing to bet almost anything that you never actually need to
do random access into a String ;-)
More information about the swift-evolution