In Ruby, how does `begin ... end while cond` differ from the `stmt while cond` modifier, and why does RuboCop's Lint/Loop flag it?

## Two loop keywords, one rule Ruby has two condition-driven loop keywords: - `while cond` repeats the body **as long as** `cond` is truthy. - `until cond` repeats the body **as long as** `cond` is falsy; it is `while` with the test negated. Both check the condition **before** every pass. If the condition already ends the loop, the body never runs. The `do` after the condition is optional, and when the condition finally ends the loop, the whole expression evaluates to `nil`. ```ruby attempt = 0 until attempt >= 3 attempt += 1 end attempt # => 3 ``` ## The modifier form Like `if` and `unless`, both keywords can follow a statement as a **modifier**: ```ruby n = 5 n += 1 while n < 3 n # => 5 -- the test ran first and was false ``` For an ordinary statement, including one in parentheses, the modifier is still a **pre-test** loop. The statement may run zero times. ## The `begin ... end` exception There is one shape where Ruby changes the order. When the modifier follows a `begin ... end` block, the body runs **first** and the condition is checked after each pass: ```ruby n = 5 begin n += 1 end while n < 3 n # => 6 -- the body ran once before the test ``` This is Ruby's do-while. The language reference documents it as the way to write "a while loop that runs the body once before the condition". The parser records the difference as a flag on the loop node (Prism calls it `BEGIN_MODIFIER`), so the same keyword produces two different evaluation orders depending on what precedes it. | Form | Condition checked | Minimum runs | |---|---|---| | `while cond ... end` | before each pass | 0 | | `stmt while cond` | before each pass | 0 | | `(stmt) while cond` | before each pass | 0 | | `begin ... end while cond` | after each pass | 1 | | `loop do ... break unless cond end` | wherever you put the `break` | 1 if the break is last | ## Why `Lint/Loop` flags it The problem is not that the post-test form is wrong; it is that it **looks like** the modifier form and behaves differently. A reader who knows that `x while cond` may run zero times will misread `begin ... end while cond`. RuboCop's `Lint/Loop` cop, enabled by default, reports `begin/end/while` and `begin/end/until` and suggests an explicit alternative: ```ruby loop do reading = sensor.read break unless reading.nil? end ``` Here the order is visible: the body runs, then the exit test at the bottom decides. The cop's autocorrection is marked unsafe for two reasons documented in its source: 1. `Kernel#loop` takes a block, and a block opens a new scope, so a variable first assigned inside the body is no longer visible after the loop. In the example, `reading` must be initialised before `loop` if later code needs it. 2. `Kernel#loop` rescues `StopIteration`, so a body that raises it would end the loop quietly instead of propagating. ## A greenhouse example A controller must read a humidity sensor at least once and keep reading while the driver returns `nil` for a failed sample: ```ruby reading = nil loop do reading = sensor.read break if reading end ``` The same logic with the post-test form is shorter, but the `end until reading` at the bottom is easy to misread as a pre-test modifier: ```ruby begin reading = sensor.read end until reading ``` Both run the read at least once. A capped version — stop after a few failures and report — is usually what a real controller wants, and `Integer#times` expresses that count directly. ## What to say in an interview - `while` and `until` test first; the body can run zero times. - A modifier on a normal statement also tests first. - A modifier after `begin ... end` tests last, so the body runs at least once. - `Lint/Loop` prefers `loop do ... break ... end` because it makes the exit point explicit. - Both keywords evaluate to `nil` when their condition ends them.