It's not about the space, it's about the use of what is supposed to represent written glyphs for graphical effects which are becoming increasingly complex. There is nothing in principle that would limit infinite expansion of the space of emojis, and their capabilities.
The functionality was always there (think ê vs ê), so properly handling glyph segmenting a string requires returning a `Vec<Vec<char>>`, which makes these emoji actually very useful: it makes it more likely that implementations will do the right thing by giving people from "predominantly ASCII" locales a "tool" to exercise those codepaths. Widespread emoji adoption is likely the best thing that could have happened to proper text handling for users outside of the anglosphere.
Combining characters are trivial to deal with. Some of the new emoji compounding uses things like the color squares to alter an emoji and you are forced to have a table of which emoji are dual function to know if they merge with their neighbors or stand by themselves.
Nothing else in Unicode acts like that. You can't properly parse complex emoji glyphs from a random starting point because you need previous context to know how to interpret following codepoints. With combining characters you just skip ahead to the next non-combiner.
With Unicode, concerns of running out of space are absurd. There are almost a million unallocated codepoints. At the rate codepoints are being allocated, we won't run out for at least 250 years, and emoji are less than 3% of those allocations. Also, the biggest limitation on the number of codepoints is UTF-16, which we have to pray is dead by the late 2200s (when it dies, we'll have over 2 billion unallocated codepoints.)
It's not about the space, it's about the use of what is supposed to represent written glyphs for graphical effects which are becoming increasingly complex. There is nothing in principle that would limit infinite expansion of the space of emojis, and their capabilities.
The encoding has gotten out of hand with compound emoji. Splitting them on glyph boundaries is non-trivial.
The functionality was always there (think ê vs ê), so properly handling glyph segmenting a string requires returning a `Vec<Vec<char>>`, which makes these emoji actually very useful: it makes it more likely that implementations will do the right thing by giving people from "predominantly ASCII" locales a "tool" to exercise those codepaths. Widespread emoji adoption is likely the best thing that could have happened to proper text handling for users outside of the anglosphere.
Combining characters are trivial to deal with. Some of the new emoji compounding uses things like the color squares to alter an emoji and you are forced to have a table of which emoji are dual function to know if they merge with their neighbors or stand by themselves.
Nothing else in Unicode acts like that. You can't properly parse complex emoji glyphs from a random starting point because you need previous context to know how to interpret following codepoints. With combining characters you just skip ahead to the next non-combiner.
640K should be enough for anybody.
With Unicode, concerns of running out of space are absurd. There are almost a million unallocated codepoints. At the rate codepoints are being allocated, we won't run out for at least 250 years, and emoji are less than 3% of those allocations. Also, the biggest limitation on the number of codepoints is UTF-16, which we have to pray is dead by the late 2200s (when it dies, we'll have over 2 billion unallocated codepoints.)