rust-lang / rust-lang/rust-by-example

Confusing closure example

Open
#1,611 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Handlebars
Stars
8.1k
Forks
1.6k
PR merge metrics
No merged PRs in 30d

Description

Hi,

it's just caught my eye, that closures from this example don't really explain what a capture means.

https://github.com/rust-lang/rust-by-example/blob/767a6bd9727a596d7cfdbaeee475e65b2670ea3a/src/fn/closures.md?plain=1#L29-L30

As a totally new to rust I've got an impression that closures in rust capture the whole outer scope disregards of where the closure is defined in code, e.g., before or after the captured variable.

Upd. and then I realised that, probably, this example should never be read as "an example of capturing". What confused me is the beginning explaining what a closure is, giving its probably the most important characteristic first.

Still I would add a capture example here, otherwise it seems just like another way of defining a function (which is probably true as well), with even more confusing variable i having the same name as a function/closure argument i.

Best regards,
Mikhail

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with src/fn/closures.md at the linked lines and read the surrounding closure introduction. Clarify what capture means and add an explicit capture example, avoiding ambiguity around the variable named i. Done means the example distinguishes ordinary closure arguments from captured outer variables and the documentation remains understandable to Rust newcomers.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.