Closed
Description
This code snippet illustrates a problem I've always had with the Rust compiler's error messages:
use std::ops::Deref;
fn foo<Inner: Deref<Target=[u8]>, Outer: Deref<Target=[Inner]>>(buf: Outer) {}
pub fn main() {
let data = [0_u8];
foo(&&[&data]);
}
The compiler error is:
error[E0271]: type mismatch resolving `<&&[&[u8; 1]; 1] as std::ops::Deref>::Target == [_]`
--> src/main.rs:7:5
|
7 | foo(&&[&data]);
| ^^^ expected reference, found slice
|
= note: expected type `&[&[u8; 1]; 1]`
found type `[_]`
note: required by `foo`
--> src/main.rs:3:1
|
3 | fn foo<Inner: Deref<Target=[u8]>, Outer: Deref<Target=[Inner]>>(buf: Outer) {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Intuitively, for me, found
and expected
are swapped. I expect the function to be the point of reference, and therefore the expected
value and I expect the call site to be the candidate, and therefore the found
value. However it seems reverse. Above you can see the expected
type is the call site's &[&[u8; 1]; 1]
and the found
type is the function's [_]
. I this often slows me down when chasing compile errors as I have to stop and mentally reverse my perception about expected and found.
I hesitate to call this a bug, as I think it's a matter of opinion. But it does feel the opposite of intuitive for me.
$ rustc --version
rustc 1.28.0 (9634041f0 2018-07-30)