Compiler can't consistently auto-coerce fn pointers

[jamesmunns]

I noticed that when matching and returning (const) fn items directly, the compiler was able to coerce them into the same fn type fn(u64, u64) -> u64 automatically, but when included as part of a tuple, the compiler seemingly lost this ability.

I'd probably call this more "surprising" than a "bug", since the diagnostics do hint at the right way to remediate this. Still - I wanted to report since it was suprising to me that it could handle it in the simple case and not in the next more complex type.

I tried this code:

playground link

fn main() {
    let op = "*";
    
    // Single item: totally fine!
    let func = match op {
        "+" => u64::wrapping_add,
        "*" => u64::wrapping_mul,
        _ => unimplemented!(),
    };
    println!("{}", func(2, 20));
    
    // NOT FINE
    //
    //   = note: expected tuple `({integer}, fn(_, _) -> _ {core::num::<impl u64>::wrapping_add})`
    //               found tuple `({integer}, fn(_, _) -> _ {core::num::<impl u64>::wrapping_mul})`
    //   = note: different fn items have unique types, even if their signatures are the same
    //   = help: consider casting both fn items to fn pointers using `as fn(u64, u64) -> u64`
    //
    // let (base, func) = match op {
    //     "+" => (0, u64::wrapping_add),
    //     "*" => (1, u64::wrapping_mul),
    //     _ => unimplemented!(),
    // };
    // println!("{}", func(base, 20));
    
    // Fine if we specify the type (or do manual casting)
    let (base, func): (u64, fn(u64, u64) -> u64) = match op {
        "+" => (0, u64::wrapping_add),
        "*" => (1, u64::wrapping_mul),
        _ => unimplemented!(),
    };
    println!("{}", func(base, 20));
}

I expected to see this happen: Compiler is consistent whether the fn items are directly returned or as part of an aggregate/tuple item.

Instead, this happened: Compiler only performed auto-coercion of the fn item when it was not part of an aggregate/tuple item

Meta

Repros on current stable/nightlies: 1.91.1, 2025-12-06.

[fmease]

I've only skimmed this issue but I'm quite sure this would be fixed by PR #147834 (i.e., making tuples coercion sites).

[jamesmunns]

Thanks @fmease! This might indeed be a dupe of #112856. I've followed #147834, I can retry my repro after that lands, or maybe CC @WaffleLapkin if you want to add this as a potential test case (or just try it out locally).

[WaffleLapkin]

#147834 doesn't fix this sadly, I'm still pretty sure it only affects the never type.

The problem here is two-fold:

1. We don't insert coercions unless we know we need them
2. LUB runs on the types of the (if/match/...) branches as a whole and so can only coerce those types directly

Which means that when type checking (0, u64::wrapping_add) and (1, u64::wrapping_mul) we don't add a coercion because we don't know we'll need it, and when doing LUB for the match we already have ({integer}, fn(_, _) -> _ {core::num::<impl u64>::wrapping_add}) and ({integer}, fn(_, _) -> _ {core::num::<impl u64>::wrapping_mul}) which don't have a common type they can be coerced to.

I think the fix for this would need to be something like "always add coercions eagerly and resolve (figure out if we need them and which ones) them later". But that's... a very big change to say the least. I would love to see it happen, but I'm not sure it will.

[jamesmunns]

Thank you for explaining!