Collections, Iterators & Closures

Overview

Vec and HashMap own their elements. Three iterators say how you touch them: shared, exclusive, or consuming. Adapters are lazy. Closures capture the surrounding values under the same borrow rules.

Comparative

flowchart TB
  A["Step 1 Pick the iterator kind Ready"]
  B["Step 2 What ownership do you need Ready"]
  C["Step 3a iter - yields &T Ready"]
  D["Step 3b iter_mut - yields &mut T Ready"]
  E["Step 3c into_iter - yields T, collection moved Ready"]
  F["Step 4 Chain lazy adapters - filter, map Ready"]
  G["Step 5 A consumer runs it - sum, collect, for loop Ready"]
  X["Failure path - nothing runs, must_use warning Ready"]
  A -->|continues| B
  B -->|read| C
  B -->|mutate| D
  B -->|consume| E
  C -->|continues| F
  D -->|continues| F
  E -->|continues| F
  F -->|continues| G
  F -->|no consumer at the end| X

Press Run. Snippets must be self-contained — no network, files, or native modules.

Rosetta — map, filter, sum

fn even_squares(nums: &[i32]) -> i32 {
    nums.iter().filter(|n| *n % 2 == 0).map(|n| n * n).sum()
}

function evenSquares(nums: number[]): number {
  return nums.filter((n) => n % 2 === 0).map((n) => n * n).reduce((a, b) => a + b, 0);
}

def even_squares(nums: list[int]) -> int:
    return sum(n * n for n in nums if n % 2 == 0)

The Rust chain does not build a Vec unless you collect. The TypeScript chain allocates two arrays. The Python generator expression stays lazy until sum.

collect needs a destination when several types implement FromIterator:

let evens: Vec<i32> = nums.iter().copied().filter(|n| n % 2 == 0).collect();

The turbofish form is collect::<Vec<_>>().

Rosetta — HashMap, Map, dict

use std::collections::HashMap;

fn main() {
    let mut scores = HashMap::new();
    scores.insert("ada", 10);
    scores.entry("ada").and_modify(|n| *n += 1).or_insert(0);
}

const scores = new Map<string, number>();
scores.set("ada", 10);
scores.set("ada", (scores.get("ada") ?? 0) + 1);

scores = {"ada": 10}
scores["ada"] = scores.get("ada", 0) + 1

The entry API updates in place without a second lookup fighting the borrow. HashMap order is not insertion order.

Rosetta — closures and capture

fn main() {
    let factor = 2;
    let mul = |n: i32| n * factor;
    println!("{}", mul(21));
    let owned = String::from("hi");
    let once = move || owned;
    println!("{}", once());
}

const factor = 2;
const mul = (n: number) => n * factor;
console.log(mul(21));

factor = 2
mul = lambda n: n * factor
print(mul(21))

Fn is a shared call. FnMut mutates captures. FnOnce consumes them. A move closure captures by value (Copy types are copied, others are moved), so thread and async tasks own their data. TypeScript and Python closures alias the outer binding and can keep it alive.

Interview Q&A

Pitfalls

• into_iter when the caller still needs the collection.
• Holding an iterator borrow and then pushing to the same Vec.
• Forgetting the collect type.
• Assuming HashMap order.
• Cloning every item inside map.

Go Deeper

• The Book — Common Collections
• The Book — Functional Language Features
• std::iter