You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like (as of version 0.19.1) it's possible to construct a NaN : Int through the expression
Char.fromCode 0xd800 |>Char.toCode
Doing some research, this seems unintended (and I think NaN ints are unintended in general?), as the expected return value would seem to be 0xFFFD (aka �), which is what you get when you feed most other invalid unicode codepoints to this expression.
I did a cursory search of other issues in this repo and it doesn't seem like anyone else has opened an issue for this, but please excuse me if I have missed something. oh i just read the duplicates policy! that's lovely!!
Thank you for your time!
OS: NixOS 24.11 on Linux 6.6.63
Occurs in the REPL and Firefox 133.0
The text was updated successfully, but these errors were encountered:
Funnily enough, without some form of this behavior, the elm-syntax parser would be many times slower because there is no other way to check for UTF-16 surrogates currently.
It seems like (as of version 0.19.1) it's possible to construct a
NaN : Int
through the expressionDoing some research, this seems unintended (and I think
NaN
ints are unintended in general?), as the expected return value would seem to be0xFFFD
(aka �), which is what you get when you feed most other invalid unicode codepoints to this expression.I did a cursory search of other issues in this repo and it doesn't seem like anyone else has opened an issue for this, but please excuse me if I have missed something.oh i just read the duplicates policy! that's lovely!!Thank you for your time!
OS: NixOS 24.11 on Linux 6.6.63
Occurs in the REPL and Firefox 133.0
The text was updated successfully, but these errors were encountered: