2 ms·
On the other hand, there are algorithms embedded in widely-deployed standards which are defined in terms of code points. For example, one I know quite well fro
by ubernostrum 10y ago
On the other hand, there are algorithms embedded in widely-deployed standards which are defined in terms of code points.
For example, one I know quite well from having implemented it in Python: the HTML5 color parsing algorithm (the one that turns even incredible junk strings like "chucknorris" into color values) requires, in step 7 of the parsing process, replacing any code point higher than U+FFFF with the sequence '00' (that's two instances of U+0030 DIGIT ZERO).
And personally I think code points, as the basic atomic units of Unicode, do make sense as the things strings are made up of; I wish Python had better support for identifying graphemes without third-party libraries, but since Unicode encodings all map back to code points it makes sense to me that a Unicode string is a sequence of those rather than a sequence of some more-complex concept.
- Manishearth 10y ago> there are algorithms embedded in widely-deployed standards which are defined in terms of code points. From my original comment: > You only care about code points when dealing with UTF32 strings or when implementing operations on unicode text. These operations fall in the latter. It's still pretty niche. If an algorithm is defined explicitly in terms of code points this makes sense. Stuff starts falling apart when people assign meaning to code points and use it as a placeholder for other concepts like glyph or columns of grapheme cluster.