2 ms·
At least Java I doubt it. char holds any valid UTF-16 value, so without casts I think it's probably pretty hard. Not an expert here though.
by camgunz 5y ago
At least Java I doubt it. char holds any valid UTF-16 value, so without casts I think it's probably pretty hard. Not an expert here though.
- deleted 5y ago[deleted]
- jcranmer 5y agoA Java char can hold any valid UCS-2 character, i.e. U+0000 to U+FFFF. If you need to use, say, U+1F4A9, you can't represent that with a char, so you need to use an int to hold that codepoint. A cursory glance at Java's string and character APIs reveals an awful lot of duplication between char-based "character at" and int-based "codepoint at" methods, with the former being a) broken and b) largely undeprecated despite being clearly broken.
- camgunz 5y agoYeah I think mostly you're right. The `charAt` stuff assumes UCS-2. I think the `codePointAt` stuff is fine though? Unless you think we'll get to 2 billion code points I guess (then, I've always thought Java having no unsigned types was bananas)
- recursive 5y agoIn a UTF-16 string, as implemented in java, you can end up with a char that represents only half a surrogate pair, that's not a full unicode scalar. In order to build the unicode scalar, you need the other half of the surrogate pair, which is another java "char".
- camgunz 5y agoYeah this is probably true. I haven't checked it in repl.it, but my other experiments basically showed that UTF-16 as UCS-2 is fine, getting above 0xFFFF (bigger than a Java char) causes problems. It's really disappointing, honestly. Go has rune, which is 32-bit, and adding a new rune-based API seems doable. But hey, what do I know.