I don’t think == should do normalization anyway, if only because there’s multiple variations of it to pick from
-
-
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 -
what's the use case they're worried about/
1 reply 0 retweets 0 likes -
it's perceived as improving default unicode/i18n handling for apps; can't say if that's accurate atm.
2 replies 0 retweets 0 likes -
that sounds too abstract. they should explain use-cases where it helps.
1 reply 0 retweets 0 likes -
https://github.com/apple/swift/blob/master/docs/StringDesign.rst … has some stuff; but some details are old (e.g. String is no longer a Collection)
1 reply 0 retweets 0 likes
afaik there is no rationale for `==`. It looks like someone just said "feels right"
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.