Thanks ..seeing now all this being heavily intertwined with external libs ICU etc. then yes, too much effort for too little (making fixed width Unicode strings) Why am i doing this? Unicode is a wasp nest, how do you survive, Dave ? :o)
But I do use “random string access" e.g. extracting substrings with e.g. let part = str[3..<6] with the help of the aforementioned String extension.. arrgh, great, make me a tea... TedvG > On 6 Feb 2017, at 23:25, Dave Abrahams <[email protected]> wrote: > > > 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
