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 >> <[email protected]> > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
