"expected fn item, found a different fn item" for [(f, "f"), (g, "g")] even though [f, g] infers fine

[nabijaczleweli]

I tried this code:

fn a(_: &str) {}
fn b(_: &str) {}
fn main() {
    for (f, s) in [(a, "a"), (b, "b")] {
        f(s);
    }
    // workaround
    for (f, s) in [a, b].into_iter().zip(["a", "b"]) {
        f(s);
    }
}

I expected to see this happen: both work

Instead, this happened: latter works, former errors with

error[E0308]: mismatched types
 --> a.rs:4:31
  |
4 |     for (f, s) in [(a, "a"), (b, "b")] {
  |                               ^ expected fn item, found a different fn item
  |
  = note: expected fn item `for<'a> fn(&'a _) {a}`
             found fn item `for<'a> fn(&'a _) {b}`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0308`.

Meta

rustc --version --verbose:

rustc 1.87.0 (17067e9ac 2025-05-09)
binary: rustc
commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359
commit-date: 2025-05-09
host: x86_64-unknown-linux-gnu
release: 1.87.0
LLVM version: 20.1.1

[compiler-errors]

Tuples don't participate in coercion the same way that function items do; arrays of different function items will coerce into pointers once we see that there are two different function items, but tuples get in the way of that. So we don't automatically detect that we need to coerce (f, "f") into (fn(), &str) (from the ZST function item that f evaluates to by default) so that it's type-compatible with (g, "g").

[nabijaczleweli]

yeah but they ought to ideally I think?

[compiler-errors]

That's pretty hard to do in general, since by the time we have the type of the tuple we can't apply our normal coercion adjustments to coerce arbitrary fields of the tuples, especially considering that these unsizings can be arbitrarily deep (e.g. (T, ((U, W), V))).

I don't consider this to be a bug at least.