{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibiledwn37y2yqtedbbnfcf57ev2lricxptlg7izcfdtarf6zg5fa",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3motxrty242j2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreid7pugtoag4bpyy6ap56yyamu5c3nrrr32o6s5bl4xnh2ihcytdii"
    },
    "mimeType": "image/webp",
    "size": 269022
  },
  "path": "/someb1oody/rust-guide-134-capturing-the-environment-with-closures-2l97",
  "publishedAt": "2026-06-22T03:21:26.000Z",
  "site": "https://dev.to",
  "tags": [
    "rust",
    "programming",
    "learning"
  ],
  "textContent": "##  13.4.0 Before We Begin\n\nDuring 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.\n\nIn this chapter, we will discuss some Rust features that are similar to what many languages call functional features:\n\n  * **Closures (this article)**\n  * Iterators\n  * Improving the I/O Project with Closures and Iterators\n  * Performance of Closures and Iterators\n\n\n\n**If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.**\n\n##  13.4.1 Closures Can Capture Their Environment\n\nClosures have a capability that functions do not: **a closure can access variables in the scope where it is defined.**\n\nTake a look at an example:\n\n\n\n    fn main() {\n        let x = 4;\n        let equal_to_x = |z| z == x;\n        let y = 4;\n        assert!(equal_to_x(y));\n    }\n\n\nThe closure part is:\n\n\n\n    let equal_to_x = |z| z == x;\n\n\nSome people may find it hard to distinguish the roles of `=` and `==` here, so let’s rewrite it another way:\n\n\n\n    let equal_to_x = |z| {\n        z == x;\n    }\n\n\nIn other words, the closure takes `z` as its parameter, compares it with `x` (which is 4, because `x = 4` was defined above), and returns a boolean. If they are equal, the result is `true`; otherwise it is `false`.\n\nHere the closure directly accesses the variable `x` in the same scope, which functions cannot do.\n\nBut this feature has a cost: **it introduces memory overhead**. In most cases we do not need a closure to capture its environment, and we do not want the extra overhead either. That is why functions are not allowed to capture variables from the environment, and defining and using a function never introduces this kind of overhead.\n\n##  13.4.2 How Closures Capture Values From Their Environment\n\nClosures capture values from the environment in three ways, just like functions receive parameters in three ways:\n\n  * Taking ownership, whose trait is `FnOnce` because a closure cannot take and consume the same variable more than once, so it can only be called once.\n  * Mutable borrowing, whose trait is `FnMut`\n  * Immutable borrowing, whose trait is `Fn`\n\n\n\nWhen a programmer creates a closure, Rust infers which trait should be used based on how the closure uses values from the environment:\n\n  * All closures implement `FnOnce`, because every closure can be called at least once\n  * Closures that do not move captured variables implement `FnMut`\n  * Closures that do not need mutable access to captured variables implement `Fn`\n\n\n\nIn fact, these three have an inclusion relationship: **every`Fn` also implements `FnMut`, and every `FnMut` also implements `FnOnce`.**\n\n##  13.4.3 The `move` Keyword\n\nUsing the `move` keyword before the parameter list forces a closure to take ownership of the environment values it uses. This is most useful when passing a closure to a new thread and moving data so that it belongs to that new thread.\n\nTake a look at an example:\n\n\n\n    fn main() {\n        let x = vec![1, 2, 3];\n        let equal_to_x = move |z| z == x;\n        println!(\"can't use x here {:?}\", x);\n        let y = vec![1, 2, 3];\n        assert!(equal_to_x(y));\n    }\n\n\nAfter using `move`, ownership of `x` moves into the closure, so `x` can no longer be used afterward.\n\n##  13.4.4 Best Practice\n\nWhen you specify one of the `Fn` trait bounds, **start with`Fn`**. Depending on what happens inside the closure, **the compiler will tell you if`FnOnce` or `FnMut` is needed instead.**",
  "title": "[Rust Guide] 13.4. Capturing the Environment With Closures"
}