Iterators

Iterators turn "loop over a collection and do something" into a pipeline. They're lazy: nothing actually runs until you ask for a result. The compiler usually fuses chained iterator calls into a single tight loop, so the abstraction is free at runtime.

Here's how iterators work in practice:

1. Get an iterator with .iter(), .into_iter(), .iter_mut(), or directly from .chars(), .lines(), etc.
2. Chain adapters like .map(...), .filter(...), .take(...). These are lazy.
3. Finish with a consumer like .collect(), .sum(), .count(), .any(...), or a for loop.

let names = vec!["alice", "ADMIN", "bob"];

let active: Vec<String> = names
    .iter()                              // &&str
    .filter(|n| n.starts_with('a'))      // keep some
    .map(|n| n.to_lowercase())           // transform
    .collect();                          // back to Vec<String>
// active == ["alice"]

The three "iter" methods differ in what they yield:

• .iter() yields &T (immutable references). Use when reading.
• .iter_mut() yields &mut T. Use when modifying in place.
• .into_iter() yields T (consumes the collection). Use when you don't need the original anymore.

Some adapters change the item type. After .map(|n| n.to_lowercase()), the items are Strings, not &&strs. The compiler infers types through the chain, so trust it: write the chain, then add a type annotation on the binding if needed.

.collect() is interesting: it can produce many different collections. Tell it which one with a type annotation: Vec<_>, HashMap<_, _>, String. The _ lets the compiler fill in the inner types.

Coming back to word count

Remember the three little functions from the word count chapter's exercise break? Each one was a counter, a for loop, and a return. With iterators, the whole trio shrinks to:

fn word_count(text: &str)   -> usize { text.split_whitespace().count() }
fn char_count(text: &str)   -> usize { text.chars().count() }
fn longest_word(text: &str) -> usize {
    text.split_whitespace().map(|w| w.chars().count()).max().unwrap_or(0)
}

The loops, the mut counters, the running-maximum bookkeeping: all gone. That's the payoff for spending a chapter on iterators: every "walk a collection and reduce it to one number, or to one new collection" problem gets shorter and harder to get wrong.

Summing with an iterator

A running total is a good first place to see what an iterator consumer does. Rust's iterators are lazy, so they don't do any work until you ask for a result.

You could add the values with a for loop and an accumulator. Here, sum asks the iterator for each value and collapses the sequence into one total.

Useful from the standard library

• <[T]>::iter produces an iterator of shared references over the slice.
• Iterator::sum reduces a numeric iterator to a single total. It's generic over the output type, so the compiler needs a hint: either annotate the binding (let total: i32 = ...) or use the turbofish (.sum::<i32>()).
• Iterator::product is the multiplicative cousin if you ever need a running product.

Transforming with `map`

Now you need to transform every element instead of collapsing the sequence. Read this pipeline from left to right: take ownership of the vector's items, transform each one, then collect the results into a new vector.

map is lazy: it just describes the transformation. Nothing runs until collect (or another consumer) asks for the results.

Useful from the standard library

• Vec::into_iter consumes the vec and yields owned items. That's what lets the closure call .to_lowercase() on a String directly.
• Iterator::map applies a closure to each item and produces a new iterator with the transformed items.
• Iterator::collect turns the pipeline back into a collection. The return type (Vec<String>) tells collect which collection to produce.
• str::to_lowercase returns a fresh String with the case folded.

Keeping elements with `filter`

With map you transformed every item, while filter keeps some items and drops the rest. There is one borrowing detail to watch: .iter() yields &T, but filter gives its closure another reference on top, so the closure sees &&T.

That's why you'll often see **c == ... or s.starts_with(...) (which auto-derefs) instead of plain c == .... If the compiler reports a missing &, the iterators entry in the cheatsheet shows the reference layers side by side.

Useful from the standard library

• Iterator::filter keeps only items where the predicate returns true. The closure receives a reference to the item, regardless of whether the iterator yields owned values or borrows.
• str::starts_with takes a char (or another &str) and answers yes/no. Method-call syntax auto-derefs through the extra reference.
• collect() here picks Vec<&str> straight from the return type. No turbofish needed.

Filter, then own the result

This time the input is a &[&str], a borrowed slice of borrowed strings, so the iterator yields &&str. We sidestep that double-reference by returning owned Strings; the lesson here is iterators, not lifetimes.

str::to_string converts each surviving &&str into an owned String through auto-deref. Chain it after your filter with a map, then collect into a Vec.

Useful from the standard library

• Iterator::filter again. Same closure structure; auto-deref still saves you for .ends_with(".rs").
• Iterator::map is what converts the surviving &&strs into owned Strings.
• str::to_string converts a borrowed string slice into an owned String. Auto-deref reaches through the extra reference for you.
• str::ends_with is the suffix check used by the predicate.

Wrapping up iterators

You collapsed a numeric vector with sum, transformed every element with map, kept just the matching ones with filter, and combined filter with map to convert borrowed slices into owned strings.

What we learned

• An iterator pipeline starts with .iter(), .iter_mut(), .into_iter(), or a method such as .chars() or .lines(). Lazy adapters describe what should happen to each item. A consumer finishes the pipeline by asking for results.
• iter yields &T, iter_mut yields &mut T, into_iter moves out of the collection and yields T. Pick the one that matches what you intend to do with each item.
• Adapters (map, filter, take, skip, ...) describe the pipeline but do nothing on their own. The actual work happens when a consumer (collect, sum, count, for loop) asks for results.
• collect is generic over the target collection. The return type (or a turbofish like .collect::<Vec<_>>()) tells it what to build.
• sum and product need to know their output type. Annotate the binding or use .sum::<i32>() to keep the compiler happy.
• filter's closure always takes &T, so on a &str iterator you'll see &&str. Method calls auto-deref, so .starts_with(...) Just Works; comparison operators sometimes need an explicit *.
• The |x| ... syntax you've been seeing is a closure: an anonymous function passed as an argument. Iterators are where closures earn their keep.