[swift-evolution] Strings in Swift 4

[Dave Abrahams]

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>
> wrote:
>> 
>> 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.  
>> 
>> Nevertheless: 
>> 
>> 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 ;-)

-- 
-Dave