`assert_eq!(x, y)` doesn't coerce as well as `assert!(x == y)` does

[ilyvion]

(I don't know that this is a bug, exactly, but. Was still the best-fit template.)

I tried this code:

fn main() {
    let x: Option<&[u8]> = Some(&[1, 2]);
    assert_eq!(x, Some(&[3, 4]));
}

I expected to see this happen: This should compile, and then fail the assertion.

Instead, this happened: This fails to compile with the following error:

error[E0308]: mismatched types
 --> src/main.rs:3:19
  |
3 |     assert_eq!(x, Some(&[3, 4]));
  |                   ^^^^^^^^^^^^^ expected `Option<&[u8]>`, found `Option<&[{integer}; 2]>`
  |
  = note: expected enum `Option<&[u8]>`
             found enum `Option<&[{integer}; 2]>`

Re-writing the code as

fn main() {
    let x: Option<&[u8]> = Some(&[1, 2]);
    assert!(x == Some(&[3, 4]));
}

works as expected.

Also, yes, I know that it's possible to manually coerce this by writing assert_eq!(x, Some(&[3, 4][..]));, but it's disappointing that I should have to.

Meta

rustc --version --verbose:

Used the playground; it reports 1.77.0-nightly (2024-01-22 d5fd0997291ca0135401)

[mahmudsudo]

i think this is due to the type inference of the compiler , if the same scenario is created as follows :
fn main() { let x: Option<&[i32; 2]> = Some(&[1, 2]); assert_eq!(x, Some(&[3, 4])); }
it compiles with the desired error

the type inference is made by assert_eq to be a primitive type .

[mahmudsudo]

i hope this help

[fmease]

Btw, I've marked this with T-libs instead of T-compiler since assert_eq uses a match statement under the hood (which isn't a coercion point I think) to avoid moves or something like that (I forgot the specifics) and I think that we should first try to adjust the definition of assert_eq before attempting to modify the inference/coercion rules in the compiler.

[mahmudsudo]

yes exactly, assert_eq uses a match statement to aid reborrowing and avoid moving

[ilyvion]

@mahmudsudo

if the same scenario is created as follows : fn main() { let x: Option<&[i32; 2]> = Some(&[1, 2]); assert_eq!(x, Some(&[3, 4])); } it compiles with the desired error

1. This is more or less an inversion of adding the [..] to the "inline" array; the very thing I'm complaining about having to do.
2. The x in the code that inspired me to even make this issue was a value returned to me by an API; so I don't even have the option of changing its type.
3. There are several (countless?) ways to rewrite the assertion to make the compiler accept this; that's not really the point.

[JaniM]

Triage note: This problem can be reduced to

fn assert_eq_type_coercion() {
    let x: Option<&[u8]> = Some(&[1, 2]);
    x == Some(&[3, 4]);     // OK
    &x == &Some(&[3, 4]);   // Fails
    *&x == *&Some(&[3, 4]); // Fails
}

I don't think there's a way to solve this at the library side unless we require the values passed to assert_eq have the same type. That'd be a highly breaking change.