If-else type checking fails with trait method calls and closures about rust HOT 5 CLOSED

You can simplify it to something like this:

fn main() {
    let a = if true {
        Box::new(|| 42)
    } else {
        Box::new(|| 42)
    };
}

Error message compiler gives is this one:

error[E0308]: `if` and `else` have incompatible types
 --> src/lib.rs:5:9
  |
2 |       let a = if true {
  |  _____________-
3 | |         Box::new(|| 42)
  | |         ---------------
  | |         |        |
  | |         |        the expected closure
  | |         expected because of this
4 | |     } else {
5 | |         Box::new(|| 42)
  | |         ^^^^^^^^^^^^^^^ expected `Box<{[email protected]:3:18}>`, found `Box<{[email protected]:5:18}>`
6 | |     };
  | |_____- `if` and `else` have incompatible types
  |
  = note: expected struct `std::boxed::Box<{closure@src/lib.rs:3:18: 3:20}>`
             found struct `std::boxed::Box<{closure@src/lib.rs:5:18: 5:20}>`
  = note: no two closures, even if identical, have the same type
  = help: consider boxing your closure and/or using it as a trait object

For more information about this error, try `rustc --explain E0308`.
error: could not compile `mini` (lib) due to 1 previous error

Different closures have different types even if closures are identical so behavior is somewhat expected. You can make it work if you ask the compiler to make a trait object specifically:

fn main() {
    let a: Box<dyn FnOnce() -> usize> = if true {
        Box::new(|| 42)
    } else {
        Box::new(|| 42)
    };
}

The error message can probably be improved a bit - closures are clearly boxed so suggesting to box it is odd.

from rust.

I'd expect the compiler to be able to infer that both closures in the if-statement have trait object type Box<dyn Fn() -> i32>, as this is type of param. This happens when instead of using type parameter I in signature of foo as type of param we use Box<dyn Fn() -> i32>. But if we use param : I suddenly this does not work. Note that signature of foo in the impl block is identical in both cases.

from rust.

I think that to get to Box<dyn Fn() -> i32> compiler needs to throw away the actual unnameable closure type and turn it into a trait object and this is not happening unless you ask it to. Example with if statement in your case fails to compile because the compiler first need to figure out what type if should be, but branches have different types.

from rust.

I see. I'm trying to understand why swapping I with Box<dyn Fn() -> i32> in foo signature in trait declaration would resolve the issue and make the code compile (while again keeping the rest unchanged).

from rust.

In that case the return types of both if branches will be implicitly coerced to Box<dyn Fn() -> i32> which will cause both branches to have the same type.

from rust.