⚡️ Restore next() speed by dropping undefined field init (#1078) master
The 8.4.1 build (rolldown 1.1.3) emits uninitialized class-field declarations (`s01; s00; s11; s10;`) ahead of the constructor for both xorshift128plus and xoroshiro128plus. Under ES2022 `[[Define]]` semantics these fields are first defined as `undefined`, which can pin them to a generic Tagged representation in V8 rather than the SMI-optimized one, adding per-read overhead in the hot `next()` path — a regression versus 8.4.0, whose build emitted a plain constructor. Declare the fields with `declare` and assign them in the constructor body so the compiled output contains only the constructor assignments (no uninitialized field declarations). The fields become SMIs from their very first write. Behavior and public API are unchanged; all 96 tests pass, including the seed-42 and post-jump sequence snapshots. An isolated 200M-iteration `next()` microbenchmark shows the constructor-only emit running ~37-63% faster than the field-declaration emit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015bbmT43PSrpMa3rsBsErk6 --------- Co-authored-by: Claude <noreply@anthropic.com>