Array of tuples containing functions trip on type inference?

[glandium]

Consider the following code:

fn foo(_s: &mut [u8]) {}

fn bar(_s: &mut [u8]) {}

fn main() {
    let _works = [foo, bar];
    //let _doesnt_work = [(foo,), (bar,)];
    let _explicit_works: [(fn(&mut[u8]),);2] = [(foo,), (bar,)];
}

I expected the second assignment to be equivalent to the third.

Instead, compilation fails with:

error[E0308]: mismatched types
 --> src/main.rs:7:34
  |
7 |     let _doesnt_work = [(foo,), (bar,)];
  |                                  ^^^ expected fn item, found a different fn item
  |
  = note: expected fn item `for<'r> fn(&'r mut [u8]) {foo}`
             found fn item `for<'r> fn(&'r mut [u8]) {bar}`

Nightly has a better error message:

  = note: expected fn item `for<'r> fn(&'r mut [u8]) {foo}`
             found fn item `for<'r> fn(&'r mut [u8]) {bar}`
  = note: different `fn` items always have unique types, even if their signatures are the same
  = help: change the expected type to be function pointer `for<'r> fn(&'r mut [u8])`
  = help: if the expected type is due to type inference, cast the expected `fn` to a function pointer: `foo as for<'r> fn(&'r mut [u8])`

But with that clarification, I'd actually expect the first assignement to fail with the same error, but it doesn't.

[jonas-schievink]

I don't think coercions are supposed to work on inner fields

[eggyal]

I don't think coercions are supposed to work on inner fields

I'm not sure that holds, because _explicit_works is a working example of the exact coercion on inner fields that's required here... is this not instead an inference issue (when trying to compute a mutual supertype of two tuple types)?

[masonk]

The reference states:

a tuple is a coercion site to type (U_0, U_1, ..., U_n). Each sub-expression is a coercion site to the respective type, e.g. the zeroth sub-expression is a coercion site to type U_0.