Open Radar

 
SUMMARY

Foundation needs a higher-level way to manipulate composed character sequences, perhaps an “NSComposedCharacterString” or something to that effect.


STEPS TO REPRODUCE

When consuming data from or sending data to a web API, great pains must be taken to ensure that character counts and syntax-highlighting ranges have been adjusted for encoding differences between NSString and the data obtained from a given API. This is particularly true of emoji characters and languages with many diacritical marks, like Thai. Many web APIs are encoded in UTF-32 to make it easier to internationalize their services.

Errors caused by mishandled encoding differences can easily lead to inconsistent behavior and crashes. Unfortunately, code that leads to safe handling of these differences is often lengthy and hard to follow. There isn't a clean way of manipulating composed characters. Many times the only way to perform a basic string calculation requires enumerating every composed character in the string, one at a time, via the `NSStringEnumerationByComposedCharacterSequences` option available on NSString. 

It feels like taking the car to the mailbox when a walk should suffice.


EXPECTED RESULTS

I don't pretend to know the full implications of such an idea, but it seems to me that a higher-level solution would be broadly useful. Some kind of NSString alternative or subclass, like an "NSComposedCharacterString", which would — for example — report a length of "1" for an emoji beer mug, where NSString returns a length of "2". This would allow developers to use the typical design patterns they use when manipulating non-composed character NSStrings, leading to code that is safer and easier to follow.