3 ms·
This is a historical oddity. At the time Apple and Microsoft (plus a few others) game up with Unicode the assumption was that we’d be able to fit everything int
by xenadu02 8y ago
This is a historical oddity. At the time Apple and Microsoft (plus a few others) game up with Unicode the assumption was that we’d be able to fit everything into 16 bits.
That turned out not to be true but binary compatibility made switching to UTF-8 impossible.
- eridius 8y agoNot just binary compatibility, also API compatibility. All of the performance guarantees of NSString are based around the internal representation being UTF-16 (or ASCII). Similarly -[NSString length] is defined as the number of UTF-16 code units, and all of the subscripting / range operations are defined in terms of UTF-16 code units.
- int_19h 8y agoSame thing goes for Java and .NET. It's somewhat ironic that those who were the earliest on the Unicode bandwagon ended up saddled with all this compatibility garbage...
- eridius 8y agoWhat gets me is that this affects later languages too. For example, Swift's internal String storage is either ASCII or UTF-16, precisely because it needs to maintain NSString's performance guarantees when bridging to Obj-C. That said, it seems the plan for Swift 5 is to change String's internal storage to be UTF-8, and then when bridging to NSString it will provide amortized constant-time UTF-16 codepoint access by calculating and caching "breadcrumbs" for fast lookup of UTF-16 offsets.