Support higher Unicode ranges for Char.fromCode

[Janiczek]

> Char.fromCode 0x1F0A1 == Char.fromCode 0xF0A1
True : Bool

> Char.fromCode 0x1F0A1
'' : Char

> Char.fromCode 0xF0A1
'' : Char

I'm trying 0x1F0A1 = 🂡, I'm getting 0xF0A1 = .
That's because Elm uses JavaScript's String.fromCharCode which doesn't support higher Unicode ranges.
To mitigate that, String.fromCodePoint should be used.

As a sidenote, maybe toCode could be also updated to use String.codePointAt instead of String.charCodeAt?

[process-bot]

Thanks for the pull request! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[process-bot]

Thanks for the pull request! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[lukewestby]

Unfortunately String.fromCodePoint isn't well supported by browsers so it would need to be polyfilled. Even a low-level polyfill of this function is a lot slower than the native, as demonstrated by the benchmark below

http://jsbin.com/taraguwaja/1/edit?js,console

[lukewestby]

Unfortunately String.fromCodePoint isn't well supported by browsers so it would need to be polyfilled. Even a low-level polyfill of this function is a lot slower than the native, as demonstrated by the benchmark below

http://jsbin.com/taraguwaja/1/edit?js,console

[evancz]

Fixed in elm-lang@bf16ca8 with an implementation that is cross-browser and should be reasonably fast. In the BMP, it usually adds just one check, so it's not much of an additional overhead.

@lukewestby, most polyfills have lots of code to handle all the bad data that could be passed in. What does .codePointAt do on objects? On arrays? Etc. In this case I just learned a lot about UTF-16 for some recent parser work, and it turns out that it's not so hard to sort out.

If folks are curious, I used the formulas from here for surrogate pairs.

[evancz]

Fixed in elm-lang@bf16ca8 with an implementation that is cross-browser and should be reasonably fast. In the BMP, it usually adds just one check, so it's not much of an additional overhead.

@lukewestby, most polyfills have lots of code to handle all the bad data that could be passed in. What does .codePointAt do on objects? On arrays? Etc. In this case I just learned a lot about UTF-16 for some recent parser work, and it turns out that it's not so hard to sort out.

If folks are curious, I used the formulas from here for surrogate pairs.