moonbitlang / core / 5650

90%

push

github

refactor: use range loops instead of C-style `for`

Rewrites `for i = s; i < n; i = i + 1 { .. }` as `for i in s..<n { .. }`
(and the one `<=` site as `s..<=n`). 50 loops in 10 files.

Found with moongrep, two patterns:

    for $(i:id) = $(s:exp); $(i:id) <  $(n:exp); $(i:id) = $(i:id) + 1 { $(body:exp) }
    for $(i:id) = $(s:exp); $(i:id) <= $(n:exp); $(i:id) = $(i:id) + 1 { $(body:exp) }

Repeating `$(i:id)` across the init binder, the condition and the update
is what makes this precise: `id` compares normalized names, so the three
occurrences are required to be the same variable. Generalising the start
from the literal `0` to `$(s:exp)` added 3 sites over the `0`-anchored
version.

Three conversion hazards were checked across all candidates:

- **loop variable reassigned in the body** — a range loop's variable is
  immutable, so this would not compile. 0 sites.
- **`continue` in the body** — 0 sites.
- **non-invariant bound.** The C-style condition re-evaluates `n` every
  iteration; `s..<n` evaluates it once. 7 sites have a call in the bound
  (all `.length()`), so each was checked individually: every one iterates
  over one collection while mutating a *different* one, so the length is
  in fact invariant and the rewrite is sound. This is also a small win —
  the call now happens once instead of per-iteration.

Steps other than 1 are excluded: MoonBit range loops have no step, so
the 8 further sites matching `$(i:id) = $(i:id) + $(k:const)` cannot be
expressed this way and are left alone.

Tests pass on wasm-gc, js and native; `moon info` reports no `.mbti`
change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

4 of 0 new or added lines in 0 files covered. (NaN%)

15788 of 17458 relevant lines covered (90.43%)

173610.85 hits per line