On 5/18/24 4:10 PM, Tiago Freire wrote:

 

> 3. Add support for Unicode-aware case conversions and case-insensitive comparisons.

I would discourage against doing this. And the main reason for doing this is considering why a developer would want to do this.
I personally don’t know many applications where “case-conversion” is a thing that you want to do (it is mostly a weird quirk of how humans have abused a writing system rather than anything else, many cultures don’t have this problem), except for the most common ones related to operating system interfaces that are case-insensitive such as files on NTFS. Everyone wants to do case comparisons/conversions because of NTFS, but this would be wrong, not only because NTFS is now “optionally” case-insensitive, the set of characters in NTFS that have a case and are considered matching sans-case is not the same as what Unicode defines (or will define in the future).

We've discussed case-insensitive filesystems in the past and we recognize that the only right way to work with them is to let the filesystem driver handle whatever case folding and normalization is required. Apple's HFS+ got locked to Unicode 3.2 and Apple's APFS is locked to Unicode 9.0.

If we provide this to users, it will far more likely do something that the user did not intend but will look right in testing. I’m not sure if a user would be better of not to be provided with this, and be forced to implement a solution that actually works for their use case.

Correct handling of case is complicated and there are use cases that are generally applicable to many domains; searching documents for example. The possibility of a feature being misused isn't great motivation for not making the feature available for appropriate uses.

Tom.