In Ruby, what does declaring a block-local variable with |row; total| do, and when would you reach for one?

## Blocks share the surrounding locals A Ruby block is written inside a method body (or at the top level) and can see the **local variables** that exist there. Assignment inside the block follows a simple rule: - If a local with that name **already exists** outside the block, assignment inside the block **updates the outer variable**. - If it does **not** exist yet, assignment creates a new local that lives only for that run of the block. That first rule is usually what you want, for example when accumulating into `sum`. It becomes a bug when the block reuses a name by accident. ```ruby total = 0 [3, 4].each { |n| total = n } total # => 4, the outer variable was overwritten ``` ## Declaring block-local variables The block parameter list accepts a semicolon. **Names after the `;` are block-local variables**: ```ruby total = 0 [3, 4].each { |n; total| total = n } total # => 0, the outer variable is untouched ``` Facts about them: 1. They are **new locals** scoped to the block, even when an outer variable has the same name. 2. They start as **`nil`** on every run of the block; nothing carries over from the previous run. 3. They receive **no arguments**: `yield` fills the ordinary parameters before the `;` only. 4. The list may contain only block-locals: `|; tmp, idx|` is valid. Ruby's own calling-methods reference shows the effect with a `place` variable: with `; place` declared, the outer `place` keeps its value; without it, the block's assignment replaces it. ## Parameters shadow too A block **parameter** with the same name as an outer local also shadows it: ```ruby row = "header" ["a", "b"].each { |row| row.upcase } row # => "header" ``` Ruby 2.6 removed the old "shadowing outer local variable" warning for this case, so the shadowing is silent. Block-local variables extend the same protection to scratch names that are not parameters. | Declaration | Outer `total` after the block | |---|---| | `{ \|n\| total = n }` | overwritten | | `{ \|n; total\| total = n }` | unchanged | | `{ \|total\| total = 1 }` | unchanged (parameter shadows) | ## Interaction with it and numbered parameters A block that declares anything between the pipes, even only block-locals, is treated as having **ordinary parameters**. Ruby then rejects the implicit parameters: - `proc { |; tmp| _1 }` is a `SyntaxError`: "numbered parameters are not allowed when an ordinary parameter is defined". - `proc { |; tmp| it }` is a `SyntaxError`: "'it' is not allowed when an ordinary parameter is defined". If you need a scratch variable in a short block that uses `it`, name the parameter explicitly instead. ## Tracing a run Consider `["a,1", "b,2"].each do |raw; line| ... end` in a method that already set `line = "== report =="`: 1. The first run binds `raw` to `"a,1"` and creates a **fresh** `line`, set to `nil`. 2. The block assigns `line = "a -> 1"`; only the block's `line` changes. 3. The second run gets **another fresh** `line`, again `nil`, before its own assignment. 4. After `each` finishes, the method's `line` still holds `"== report =="`. Without `; line`, step 2 would overwrite the method's variable, and any code after the loop that expected the header would print the last row instead. ## When it is worth using Block-local variables are rare in modern Ruby code, and many developers have never written one. They earn their place when: - a **long method** already has a local such as `result` or `line`, and a block deep inside wants a temporary with the same natural name; - code is being **pasted into a block** and you want a guarantee it cannot clobber the method's state; - you want to **document** that a temporary belongs only to the block. Most teams prefer the simpler fix of extracting the block's body into a small method or choosing a distinct name, which avoids the question entirely. Knowing the syntax still matters for reading older code and for explaining how block scope works.