Iterator + Closure Patterns

Closures power iterator adapters for expressive, lazy data pipelines.

Recipe

fn active_names(users: &[(&str, bool)]) -> Vec<String> {
    users.iter()
        .filter(|(_, active)| *active)
        .map(|(name, _)| name.to_uppercase())
        .collect()
}

When to reach for this: Transforming collections without intermediate mutation.

Working Example

#[derive(Debug)]
struct Order { total: u32, vip: bool }
 
fn discount_summary(orders: &[Order]) -> (u32, u32) {
    let vip_total: u32 = orders.iter()
        .filter(|o| o.vip)
        .map(|o| o.total)
        .sum();
    let regular: u32 = orders.iter()
        .filter(|o| !o.vip)
        .map(|o| o.total / 2)
        .sum();
    (vip_total, regular)
}

What this demonstrates:

• Multiple passes acceptable for clarity (or combine with fold)
• Closures in filter/map
• Collect to sum consumer

Deep Dive

Prefer filter_map over filter+map. Use fold for single-pass aggregation. then (1.51+) chains Option steps.

Gotchas

• Cloning in map - |s| s.clone(). Fix: Use references earlier.
• Mutable closure in parallel rayon - Fn not FnMut - sync only.
• Long closure chains - Extract named functions.
• needless collect - clippy warning.
• move closure in loop - May force move entire env each iter.

Alternatives

FAQs

Related

• Iterator Adapters
• Higher-Order Functions
• Consuming Iterators
• Data Parallelism with Rayon

Stack versions: This page was written for Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, and Polars 0.46+.