What is the effect of writing the value of the option when returning the closure?

Question

        let value = Some(0);
        let closure = if value.is_some() {
            |value: i32| false
        } else {
            |value: i32| true
        };

The code above does not produce a compilation error However, the code below has a compilation error What's the reason?

        let closure = if let Some(option_value) = value {
            |value: i32| option_value == value
        } else {
            |value: i32| true
        };

They're all different types

`if` and `else` have incompatible types
no two closures, even if identical, have the same type
consider boxing your closure and/or using it as a trait object

Box is a solution. But I don't know the difference yet

let closure = if let Some(option_value) = value {
    Box::new(move |value: i32| option_value == value)
} else {
    Box::new(|value: i32| true)
};

Does this answer your question? [Expected closure, found a different closure](https://stackoverflow.com/questions/39083375/expected-closure-found-a-different-closure) — Tobias S., Nov 04 '22 at 03:09

score 1 · Accepted Answer · answered Nov 04 '22 at 14:03

Box is a solution. But I don't know the difference yet

As baseline, every function (anonymous or not) has its own concrete type, different from all others.

However named functions and non-closure anonymous functions can be coerced to "function pointers" fn(args...) -> ret.

That is what happens in your first snippet, if you use "the unit trick":

let _: () = closure;

to know what rustc has decided the concrete type of closure is, it tells you:

found fn pointer `fn(i32) -> bool`

so because both anonymous functions are static (they don't actually close over anything), the compiler converted both into function pointers.

That doesn't work with the second snippet, because the first branch creates an actual closure, which can't be converted to a function pointer (because it's not just a function, it's also data). Hence type mismatch.

Boxing works, because it allows the creation of dynamically dispatched trait objects of type

Box<dyn Fn(i32) -> bool>

which are compatible.

score 0 · Answer 2 · answered Nov 04 '22 at 08:31

I think your mistake is that you assumed the type of both Closures is

Fn(i32) -> bool

But that is a trait, not a type, each closure has it is own type, which implements the above trait.

T: impl Fn(i32) -> bool

Box solves that issue as the type for both becomes Box<dyn Fn(i32)->bool>

What is the effect of writing the value of the option when returning the closure?

Box is a solution. But I don't know the difference yet

2 Answers2