Swift String’s ABI and UTF-8
This is really great to hear. The different internal string representations really age a language:<p>- C sort of assumes all strings are ASCII<p>- Java, C#, Obj-C, Javascript and Python2 were all written when it was assumed Unicode would have no more than 65536 characters. They all use 2 byte encodings, which has become the worst of all worlds. ASCII text is twice the size it needs to be, you still need to handle the mismatch between array length and codepoint length, and errors are harder to find because there are very few common characters that actually cross the 2 byte boundary - although the popularity of emoji has changed this.<p>- Go, Dart, Rust and Zig all return to single byte encodings. They all use UTF-8 internally, and have different functions to interact with the string as a list of bytes, and the string as a list of unicode codepoints. (In Go&#x27;s case its because Rob Pike was behind both Go and UTF8.)<p>Its delightful to see Swift stepping away from Obj-C&#x27;s mistakes and improving things internally. Although in Obj-C&#x27;s defence, NSString has always hidden its internal representation, which did a lot of work to protect developers from the footguns.<p>One of the big ironies of all this is how well C has stood the test of time. C strings interoperate beautifully with UTF8 - all thats missing is some libc helper methods to count &amp; iterate through UTF8 codepoints. strlen &#x2F; strncpy &#x2F; strcmp &#x2F; etc all work perfectly when dealing with UTF8. The only change is that you need to supply lengths in bytes not characters.