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.