5 ms·
Not just binary compatibility, also API compatibility. All of the performance guarantees of NSString are based around the internal representation being UTF-16 (
by eridius 8y ago
Not 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.