Functions in std should accept `&[T; N]` whenever they accept `&[T]`

[petrochenkov]

Most of the time it happens automatically due to DST coercions &[T; N] => &[T], but sometimes additional care is required.

One example, where it currently doesn't work, is comparison operators between slices/arrays/vectors:

fn main() {
    let a: &[u8; 3] = &[1, 2, 3];
    let b: &[u8] = &[1, 2, 3];
    // Both comparisons doesn't compile
    a == b;
    b == a;
}

When #18465 is implemented, the code comparing byte string literals with slices will break. A lot of such code can be found, for example, in libstd/path.

[huonw]

cc @nick29581, maybe something to with coercions? It seems at least b == a should compile by coercing the RHS to &[u8]?

(I tried to implement #18465 and met this exact problem)

[nrc]

I'll have to have a look at the code in the morning to be sure of what's going on. I think the problem though is that we do not coerce when searching for impls, the == means we have to find an implementation of Eq (or is it PartialEq?) with Self = &[u8] and a type param bound to &[u8; 3], which I assume will not work. If that is the case, I'm not sure what we can do about it - I think doing coercions when doing trait matching is impractical, though I don't exactly recall why. I guess it could work if the RHS of PartialEq were an associated type, but I assume there are reasons we don't do that.

OTOH, I could be wrong and we should coerce and this is a bug...

[petrochenkov]

If there's no bug in coercions and impl lookup, then I'm ready to write additional impls for the comparison traits to cover references to fixed-size arrays.

[petrochenkov]

I believe this is fixed - functions in std take either &[T] (and DST coercions apply), or AsRef<[T]> (and arrays implement AsRef), or Borrow<[T]> (and arrays implement Borrow). Tricky cases like PartialEq are also covered.

"Bound-targeting coercions" as a languge feature should have a separate issue in the RFCs repository.