The Assembly Line of Rust Code
You're building a scraper. You need to fetch a URL, extract the text, parse the HTML, find the title tag, and clean up the whitespace. In Python, you might write five lines with five intermediate variables. In Rust, you can chain those steps into a single expression that reads like a sentence. This pattern is method chaining, and it's the backbone of functional style in Rust.
Chaining turns code into a specification of data flow. You describe what happens to the data, not the step-by-step state changes of every variable. The compiler enforces the type contract at every link in the chain.
How chaining works
Think of method chaining like an assembly line in a factory. Each station takes a part, modifies it, and passes it down the line. In Rust, a method call produces a value. If that value has methods of its own, you can call the next method immediately on the result. You don't need a variable to hold the intermediate state. The compiler tracks the flow for you.
The syntax is simple. You call a method, and instead of stopping, you append a dot and call the next method on the return value. This continues until you reach the final result.
/// Chains string operations to transform input.
fn process_name(name: &str) -> String {
// Start with the input string slice.
name
// Trim whitespace from both ends.
.trim()
// Convert to lowercase for consistency.
.to_lowercase()
// Replace spaces with underscores.
.replace(' ', "_")
}
The compiler evaluates this from left to right, inside out. trim() takes the &str and returns a new &str pointing to the trimmed region. to_lowercase() takes that &str, allocates a new String on the heap, and fills it with lowercase characters. replace() takes the String, searches for spaces, and returns another String with underscores. Each step consumes the result of the previous step. If the types don't line up, the compiler stops you immediately.
Trust the borrow checker. If the chain won't compile, the lifetimes are fighting you.
Chaining with iterators and options
Chaining shines when working with collections and optional values. Rust's iterators provide a rich set of methods that chain together to express complex data processing logic.
/// Finds the first even number in a list, squares it, and adds one.
fn find_even_square(numbers: &[i32]) -> Option<i32> {
// Iterate over the slice, borrowing each element.
numbers.iter()
// Filter to keep only even numbers.
.filter(|&&n| n % 2 == 0)
// Take the first match and stop iterating.
.next()
// Map the Option<i32> to Option<i32> by squaring.
.map(|&n| n * n)
// Add one to the result.
.map(|n| n + 1)
}
Here's the surprising part: iterators are lazy. Chaining methods like filter and map just builds a description of the computation. The actual loop runs only when you call collect, next, or for_each. You can chain a hundred methods and the CPU won't lift a finger until the final step. This lazy evaluation is what makes iterator chains efficient. The compiler can often optimize the entire chain into a single loop, eliminating intermediate allocations entirely.
When you chain methods on Option or Result, the same principle applies. map transforms the inner value if it exists, and and_then chains operations that might fail or return None.
Convention aside: The community prefers map for simple transformations and and_then for chaining operations that return Option or Result. Using map on an Option that returns an Option creates nested Option<Option<T>>, which is almost never what you want. Use and_then to flatten the result. This distinction keeps your types clean.
Async and fallible chains
Async code introduces a small twist. You can't chain .await directly on a method call that returns a future unless you await the previous step first. The pattern forces sequential evaluation.
/// Fetches and parses async data.
async fn fetch_title(url: &str) -> Result<String, Box<dyn std::error::Error>> {
// Fetch the response, awaiting the future.
let response = reqwest::get(url).await?;
// Extract text, awaiting the text future.
let text = response.text().await?;
// Parse and extract title synchronously.
Ok(Html::parse(&text)
.select_first("title")
.map(|t| t.inner_html())
.unwrap_or_default())
}
The ? operator is part of the chain too. It propagates errors automatically. If reqwest::get fails, the ? returns early from the function. If it succeeds, the chain continues. This keeps error handling out of the way of the main logic.
Async chaining looks slightly different because .await breaks the visual flow. You can't write .get(url).await.text().await in a single line without parentheses or intermediate variables in many cases, depending on the return types. The compiler requires you to await the future before calling methods on the resolved value. This is a deliberate design choice. It makes the suspension points explicit.
Break the chain if it stops making sense. Readability wins.
Pitfalls and compiler errors
Chaining breaks when you try to mutate a value while also reading it. If a method requires &mut self, you can't chain it after a method that borrows &self for a longer lifetime. The compiler rejects this with E0502 (cannot borrow as mutable because it is also borrowed as immutable).
/// This fails to compile due to borrowing conflicts.
fn broken_chain(mut data: Vec<i32>) {
// Borrow data immutably for the iterator.
let iter = data.iter();
// Try to mutate data while the iterator holds a borrow.
// Compiler error: E0502
data.push(42);
}
Watch out for moves too. If a method takes self by value, it consumes the input. You can't chain another method on the original variable afterward. The compiler catches this with E0382 (use of moved value).
/// This fails because to_string consumes the slice.
fn broken_move(name: &str) {
// to_string takes ownership of the string data.
let owned = name.to_string();
// name is still valid here because to_string copies.
// But if a method took self by value, this would fail.
let len = name.len();
}
Chaining can also fail silently if you forget to import a trait. Rust only looks for methods on the type itself and traits in scope. If filter isn't available, the compiler complains about a missing method. This often happens with iterators. Make sure std::iter::Iterator is in scope, or use use std::iter::Iterator; at the top. The prelude usually includes common traits, but custom traits require explicit imports.
Treat the missing method error as a signal to check your imports. The trait is likely there; it's just not in scope.
When to chain and when to stop
Use method chaining when you transform data through a linear pipeline and want to avoid cluttering the scope with temporary variables. Use intermediate variables when the chain grows beyond five steps or when you need to inspect a value at a specific stage for debugging. Use map and and_then when chaining operations over Option or Result types to propagate absence or errors implicitly. Use the ? operator when you want to chain fallible operations and exit early on the first error. Use iterator methods when processing collections, as they provide the richest set of chaining tools and benefit from lazy evaluation.
Counter-intuitive but true: the more you chain, the harder it becomes to add logging or branching logic. If you need to branch based on an intermediate value, break the chain.