Swift string comparison doesn't consider ligatures equivalent to their components

[wadetregaskis]

@xwu

The overall point I'm making is that you needn't—and shouldn't—be trying to discover these from scratch and case-by-case…

100% agree.

@xwu

…as the resources and standards from folks who've thought about this are out there. Furthermore, there's much about UX and security considerations (including how they intersect with localization and internationalization) that are use case–specific and, thus, requires developers to hold it right because it exceeds the remit of any general-purpose APIs. But the resources are there.

Here we disagree, although to be clear I don't know that you're wrong, I just am hoping you are. Optimistically, at least.

It's precisely because this problem space is truly gnarly and requires ridiculous levels of intelligence and experience that it shouldn't be left to every individual developer to not only address but also to even know they need to know it.

In principle that is, to be clear. Again, maybe this problem is truly intractable. Maybe it truly is impossible to have a sane default that covers every case in a sufficiently safe way (however we might define that).

Maybe Swift's already very nearly there. But it can't be exactly there yet, because it still thinks "office" != "office".