r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Allows easily checking whether a string is in a particular case.

Isn't this done with .is_ methods on str? It feels a little confusing to compare an iterator (which might be halfway through the result or empty) with &str. Do we have precedent for Iterator / slice comparisons anywhere?

Isn't this done with .is_ methods on str?

Those methods do not currently exist. It might make sense to add e.g. .is_in_uppercase() and .is_in_lowercase() to str. However, titlecase is determined word-by-word, so it would have to be e.g. .is_word_in_titlecase() instead. By exposing the more primitive operation, this PR avoids that complexity, while also being more flexible for users.

Do we have precedent for Iterator / slice comparisons anywhere?

Not that I know of. However, ToUppercase/ToLowercase/ToTitlecase are already more than just iterators, as they implement Display.

Hm, okay. I think that makes some sense. Let's see what libs-api thinks (should be in their meeting queue).

An additional minor benefit of the proposed API is that it would allow removing .to_string() from many doc-comment examples in char/methods.rs; making them more concise will hopefully make them more clear as well. (Will do in a follow-up if this is accepted)

It seems T-libs-api wasn't a fan of this, and had some alternative suggestions (https://hackmd.io/3iG4g-ofShaMgcP_OYHCEw#waiting-on-team-rusttf154287-Add-PartialEq-and-Eq-impls-to-the-character-case-iterators). I'll go through them one by one:

Reject this PR as written and open to:

• is_lowercase/is_uppercase for str

I would be open to adding those. However, as I explained above, they don't extend neatly to titlecase. Also, they don't work for people who can't easily use str, e.g. because they are working in UTF16, or using a fancy data structure like ropes to store their strings. Having an API for this on char is more flexible, and allows these users to easily make use of core's data tables.

It doesn't necessarily have to be this PR's API, however. For example, we could have methods on char instead. I think the PartialEq approach is nice because it corresponds to Unicode's definitions, but that's not hugely important.

• potentially ading eq_ignore_case methods (if they don't add too much unicode overhead and they're compiled out for people not using them)

Overhead should not be a problem. Case folding is primarily based on the lowercase mapping, so we would only need a small table for the difference. However, there are other issues:

• Case-folding equality can't be checked character-by-character. "ßs" and "sß" case-fold to the same string ("sss"), but a naïve char-by-char equality check will consider them unequal. A .to_case_folded() method on char would be useful, but the resulting iterator perhaps should not have PartialEq<Self>, or at least should warn prominently in the docs about the footgun.
• If you are comparing strings ignoring case, you probably also want to consider NF(K)C-equivalent strings to be equal. Adding NF(K)C normalization to the standard library would be a substantially more involved endeavor. See the Unicode spec for more info.

• ask about the eq method on iterator

It doesn't optimize well, unfortunately.

We discussed this PR in this week's @rust-lang/libs-api meeting and decided against this proposal. We would, however, be open to addressing this usecase through any or all of adding is_uppercase/is_lowercase methods on str, or adding eq_ignore_case if the implementation isn't too gnarly. Alternatively, Iterators already have an eq method - that could be useful here. itertools has an assert_eq for iterators that uses it, for instance. Thanks!