On 21/05/2024 19.44, Jens Maurer via SG16 wrote:

> For everybody else (and I posit that includes a large fraction of users that need case-insensitive stuff to begin with), having support in the standard library may outweigh the disadvantage of that support lagging a few Unicode versions behind.

We have to keep in mind that the lag we are talking about is measured in years, not months.
And what kind of user is doing case-insensitive stuff (in Unicode) where they don't care to update when a newer set of cased characters is available?
If casing is important for what they are doing why wouldn't they want to update? What kind of application are they doing where casing is kind of important but not really?


> What wrongness are we discussing here?
As an example, using a Unicode compliant case-insensitive comparison to figure out if 2 paths correspond to the same node, would be wrong.
(and this would be precisely the kind of user who wouldn't care to update)

> I disagree with that characterization. Bold claims need lots of evidence and rationale.

It maybe that my vision of this is colored by my own personal experience of what people actually want when they ask for casing features and having seen this kind of thing play out.
I admit to that, it is personal experience.
But I think the question should still be asked as to "why someone wants case conversion or case insensitive comparisons",
1. is it because they are processing text as text?
or
2. is it because of Windows OS behavior?

I don't think it is an unreasonable thing to suspect, given that the quote from the lifted point (which wasn't my own) that supported this feature displays a very similar dynamic.

I'm not saying that the feature should be off the table permanently. But I'm definitely saying that it is not as important as transcoding is.
And that transcoding should be completed and done before figuring out these other secondary features.
And that we should be careful in rushing casing functions which has the potential of being outdated and produce the wrong behavior as an external standard gets updated (causing either incompatible behavior or incorrect behavior depending on what gets updated).
It would be very misfortunate to have to deal with this last problem, thinking that we are helping programmers do 1 if what they are trying to do is 2 (and this feature doesn't even help them).

We should ask that question first.

I don't think casing is important and I wanted to avoid discussing it before transcoding is a done deal... which is precisely what I am doing right now.