[Rust Guide] 13.3. Storing Closures With Generic Parameters and Fn Traits

13.3.0 Before We Begin

During its design, Rust drew inspiration from many languages, and functional programming had a particularly strong influence on Rust. Functional programming often includes passing functions as values to parameters, returning them from other functions, assigning them to variables for later execution, and so on.

In this chapter, we will discuss some Rust features that are similar to what many languages call functional features:

• Closures (this article)
• Iterators
• Improving the I/O Project with Closures and Iterators
• Performance of Closures and Iterators

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

13.3.1 Review

Do you remember the example from 13.1?

Build a program that generates a personalized workout plan based on factors such as a person's body metrics. The algorithm itself is not the point; the important part is that it takes a few seconds to run. Our goal is to avoid unnecessary waiting for the user. More specifically, we want to call the algorithm only when necessary, and only once.

At that time, we rewrote the code as:

use std::thread;  
use std::time::Duration;  

fn main() {  
    let simulated_user_specified_value = 10;  
    let simulated_random_number = 7;  

    generate_workout(  
        simulated_user_specified_value,  
        simulated_random_number,  
    );  
}  

fn generate_workout(intensity: u32, random_number: u32) {  
    let expensive_closure = |num| {  
        println!("calculating slowly...");  
        thread::sleep(Duration::from_secs(2));  
        num  
    };  
    if intensity < 25 {  
        println!("Today, do {} pushups!", expensive_closure(intensity));  
        println!("Next, do {} situps!", expensive_closure(intensity));
    } else {  
        if random_number == 3 {  
            println!("Take a break today! Remember to stay hydrated!");  
        } else {  
            println!("Today, run for {} minutes!", expensive_closure(intensity));  
        }  
    }  
}

But there is still a problem: this does not solve the repeated-closure-call problem. When intensity is less than 25, the closure is called twice.

One possible solution is to assign the closure’s value to a local variable and let that local variable be reused by the output statements. The problem with that approach is that it introduces some code duplication.

So a better solution here is: create a struct that holds the closure and its call result. In other words, after the closure is called for the first time, store the result inside the closure holder; if the closure needs to be called again later, just use the cached result. The effect is that the closure runs only when the result is needed, and the result can be cached.

This pattern is usually called memoization or lazy evaluation.

13.3.2 Having a Struct Hold a Closure

Based on the solution above, the current problem is how to make a struct hold a closure.

A struct definition needs to know the type of every field, so if you want to store a closure inside a struct, you must specify the closure’s type.

Each closure instance has its own unique anonymous type. Even if two closures have exactly the same signature, they are still two different types. So storing closures requires generics and trait bounds. The content on generics and trait bounds is covered in 10.4. Trait Pt.2, which is worth a look.

13.3.3 Fn Trait

The Fn trait is provided by the standard library. Every closure implements at least one of the following Fn traits:

• Fn
• FnMut
• FnOnce

The differences among these three Fn traits will be covered in the next article. In this example, Fn is enough.

With that in mind, we can rewrite the example. First, create a struct:

struct Cache<T: Fn(u32) -> u32>  
{  
    calculation: T,  
    value: Option<u32>,  
}

• This struct has a generic parameter T. Since it represents the closure type, its bound is the Fn trait (Fn is enough in this example), and because the parameter and return types are u32, we write Fn(u32) -> u32.
• The field that stores the closure is calculation, and its type is T.
• The cached value is stored in the value field. Its type is u32, but we do not yet know whether the value has been calculated and cached, so we wrap it in Option, which means Option<u32>.

First, write a constructor on the struct to create instances:

impl<T: Fn(u32) -> u32> Cache<T> {  
    fn new(calculation: T) -> Cache<T> {  
        Cache {  
            calculation,  
            value: None,  
        }  
    }  
}

This looks a little messy, so we can rewrite it with a where clause:

impl<T> Cache<T>   
where   
    T: Fn(u32) -> u32  
{  
    fn new(calculation: T) -> Cache<T> {  
        Cache {  
            calculation,  
            value: None,  
        }  
    }  
}

Then, make value return the cached value if it exists, or calculate it if it does not:

fn value(&mut self, arg: u32) -> u32 {  
    match self.value {  
        Some(v) => v,  
        None => {  
            let v = (self.calculation)(arg);  
            self.value = Some(v);  
            v  
        }  
    }  
}

If the instance’s value field already has a value, return it. Otherwise calculate the value, store it in the value field, and return it.

Once that is done, we should update generate_workout to use the Cache struct:

fn generate_workout(intensity: u32, random_number: u32) {  
    let mut expensive_closure = Cache::new(|num|{  
        println!("calculating slowly...");  
        thread::sleep(Duration::from_secs(2));  
        num  
    });  
    if intensity < 25 {  
        println!("Today, do {} pushups!", expensive_closure.value(intensity));  
        println!("Next, do {} situps!", expensive_closure.value(intensity));  
    } else {  
        if random_number == 3 {  
            println!("Take a break today! Remember to stay hydrated!");  
        } else {  
            println!("Today, run for {} minutes!", expensive_closure.value(intensity));  
        }  
    }  
}

• expensive_closure is created as an instance of Cache, and we pass the closure into new. We add mut to expensive_closure because later calls may change the value stored in the value field.
• All later uses of the result go through the value method.

13.3.4 Limitations of the Cache Implementation

The Cache field here is a cache, used to store a value, but this implementation has limitations.

Here is the Cache definition and its methods:

struct Cache<T: Fn(u32) -> u32>  
{  
    calculation: T,  
    value: Option<u32>,  
}  

impl<T> Cache<T>   
where   
    T: Fn(u32) -> u32  
{  
    fn new(calculation: T) -> Cache<T> {  
        Cache {  
            calculation,  
            value: None,  
        }  
    }  

    fn value(&mut self, arg: u32) -> u32 {  
        match self.value {  
            Some(v) => v,  
            None => {  
                let v = (self.calculation)(arg);  
                self.value = Some(v);  
                v  
            }  
        }  
    }  
}

The value method always ends up with the same value: if the value field has no value, it calculates one and stores it in the field. After that, any later use of value gets the originally calculated value, no matter what argument is passed in.

That may sound a little vague, so let’s look at an example:

fn call_with_different_values(){
    let mut c = Cache::new(|a| a);
    let v1 = c.value(1);
    let v2 = c.value(2);
}

• c is an instance of Cache, and a closure is passed in.

• In the line let v1 = c.value(1);, the original value field in c is empty. At that point, passing in 1 makes the value field become Some(1) (value is an Option type).

• In the line let v2 = c.value(2);, because the value field already has a value, it directly takes the 1 stored in value and assigns it to v2, even though the argument to value in this line is different from the previous one.

If you do not want that behavior, you should use a HashMap instead of a single value, using the HashMap key as the args passed to the value method, and the value as the result of executing the closure. For example:

struct ForFun<T: Fn(u32) -> u32>  
{  
    calculation: T,  
    value: HashMap<u32, Option<u32>>,  
}  

impl<T> ForFun<T>  
where  
    T: Fn(u32) -> u32  
{  
    fn new(calculation: T) -> ForFun<T> {  
        ForFun {  
            calculation,  
            value: HashMap::new(),  
        }  
    }  

    fn value(&mut self, arg: u32) -> u32 {  
        match self.value.get(&arg) {  
            Some(v) => v.unwrap(),  
            None => {  
                let v = (self.calculation)(arg);  
                self.value.insert(arg, Some(v));  
                v  
            }  
        }  
    }  
}

This cache example can only accept the same parameter type and return type. If you want the closure’s parameter type and return type to be different, you can introduce two or more generic parameters. For example:

struct ForFun<T, R>  
where  
    T: Fn(u32) -> R,  
{  
    calculation: T,  
    value: Option<R>,  
}