does ruby bother to follow unicode tables (e.g. Ensuring various flavours of é are "equal")?
-
-
-
I don’t think == should do normalization anyway, if only because there’s multiple variations of it to pick from
1 reply 0 retweets 0 likes -
indeed.
1 reply 0 retweets 0 likes -
The Swift devs strongly disagree; they just use the "empty" locale. I'm still feelin' this decision out.
1 reply 0 retweets 0 likes -
afaict because such a comp requires allocation (in general), systems code needs a different ==...
3 replies 0 retweets 0 likes -
I think it can be done without allocation, with Iterator::eq.
1 reply 0 retweets 0 likes -
You can't do code-point-wise comparison. At least not naively. e.g. "∭∭" == "∬∬∬"
3 replies 0 retweets 0 likes -
You can do Iterator::eq("∭∭".nfkc(), "∬∬∬".nfkc()) without allocating with https://unicode-rs.github.io/unicode-normalization/unicode_normalization/trait.UnicodeNormalization.html …
1 reply 0 retweets 2 likes -
Replying to @SimonSapin @Gankro and
But that doesn’t mean == should. Which of the four forms? Does it also case-fold? Map homoglyphs? Confusables?
2 replies 0 retweets 0 likes
treating them as eq is bad for memoization and similar kinds of problems.
-
-
Replying to @wycats @SimonSapin and
unicode equivalence is an equivalence class but not a good default equivalence class imo.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.