Add lint on `&[char]`

[SoniEx2]

Since first writing this issue, all the following have come to our attention. Originally only the first point was written here:

1. &[char] doesn't provide O(1) indexing on characters, but on codepoints. a single character can be multiple codepoints (see also char.to_uppercase, which can output one or more chars!), in this case &[&str] (or equivalent) is more appropriate.
2. &[char] also doesn't provide O(1) indexing on columns, for some definition of "column". a single column can be multiple codepoints.
3. There is confusion about what &[char] actually means in a Pattern. As an example "___abc___".split(&['a', 'b', 'c'][..]).collect::<Vec<_>>() makes ["___", "", "", "___"] but some may expect it to make ["___", "___"].
   1. One way someone may expect this is as Pattern for &[char] being UTF-32. It is not. It is well-documented that Rust doesn't support UTF-32 in std.
   2. Another way is "any combination of these chars". It is also not, as that would break str.strip_prefix.
4. Even if there wasn't such confusion, &[char] may be slower than a hypothetical naive &[&str] for a small enough n, as the former requires encoding/decoding UTF-8 whereas the latter can rely on UTF-8 being a self-synchronizing prefix-free code and just match bytes.
5. If you actually wanted to use an &[char] as a Pattern, but you wanted to uppercase the chars for some reason... well, see (1).
6. For large n, &[char]: Pattern is slow. You should under no circumstances use ('a'..='z').collect::<Vec<_>>().as_slice() as a Pattern. Use |c| matches!(c, 'a'..='z') instead.

As such, there are a whole lot of issues with &[char] in practice. We think it's a good idea to lint against it.

[flip1995]

&[char] is practically a &str, not a &[&str], where it is impossible to accidentally index in between a char, but not as memory efficient. But on &str you index on codepoints (with ranges), whereas with &[char] you index on characters.

Note, that a char in Rust is not a u8, but a 4 byte character encoding.

Am I missing something?

[SoniEx2]

char is a unicode scalar value (USV). which is a subset of codepoint.

a character like á can be made of multiple codepoints.

[flip1995]

Ah TIL, thanks for the clarification.

[llogiq]

As a counterpoint, sometimes using [char] is the way to go when interfacing with scripting languages, though.

[SoniEx2]

@llogiq I'd suggest using a proper wrapper around those, and turn off the lint in the wrapper crate.

[esamudera]

Hello, I'd like to try working on this story.

So from what I can gather, the requirement is simply to create a new lint that detects &[char_type_var] and suggest converting it into &[&str_type_var] instead?

[brightly-salty]

I'm willing to attempt to implement this and submit a PR if @esamudera isn't still working on it.

[esamudera]

Hi @brightly-salty, yes please take over this issue. Thanks!

[brightly-salty]

@rustbot claim

[thomcc]

This feels a bit odd because adding a lint against a method like this is effectively deprecating it on behalf of stdlib, without going through the libs team or a wider community discussion process. The discussions on it (here and IRLO) seems far from conclusive on the subject too...