Array.isArray answers from the binding's initializer, not the value — wrong in BOTH directions, so a guard admits a number

[proggeramlug]

Summary

Array.isArray returns false for a genuine array held in an any-typed local that was reassigned to it. Every other test of the same value says it is an array, including Perry's own instanceof Array, so the runtime contradicts itself.

Three lines, no loop, no library:

let b: any = 0;
b = [b];
console.log(Array.isArray(b), b instanceof Array, b.length, JSON.stringify(b));

perry 0.5.1464   false true 1 [0]      <-- Array.isArray disagrees with instanceof Array
node  26.5.1     true  true 1 [0]

Reproduces identically with and without PERRY_NO_AUTO_OPTIMIZE=1, so it is not an auto-optimize artifact.

What triggers it

The value must reach the local by assignment, not by initializer. An any local initialized to an array literal is fine:

case	perry	node
const a: any = [1]	true	true
let b: any = 0; b = [b]	false	true
let c: any = 0; for (let i=0;i<1;i++) c = [c]	false	true
let d: any = 0; for (let i=0;i<3;i++) d = [d]	false	true
let e: any = 0; for (...) { const w: any[] = [e]; e = w }	false	true
const N = Number("3"); let f: any = 0; for (let i=0;i<N;i++) f = [f]	false	true

So it is the reassignment of an any binding, not the loop, not a constant trip count, and routing through an explicitly any[]-typed temporary does not rescue it.

Why it matters

Array.isArray is the standard way to branch on "array vs not" — it is what user code, polyfills and vendored npm packages use precisely because it is supposed to be the reliable check (it works cross-realm where instanceof does not). A silent false sends such code down the non-array branch with an array in hand. This is a wrong-answer bug, not a crash, so it fails quietly.

The self-inconsistency is the sharp edge: b instanceof Array is true, b.length is 1, typeof b is "object", and JSON.stringify(b) is [0]. Only Array.isArray dissents, so nothing downstream has a reason to suspect the value.

Related

#267 (Array.isArray() returns false on the result of [...].map(fn)) is the same symptom in a different shape and is closed; this looks like a surviving member of that family rather than a regression of it.

Found by

Probing the recursive-consumer neighbours of #7792 on main @ b1edd2340 (perry 0.5.1464), macOS arm64, oracle Node 26.5.1. The depth probe I was writing reported structuredClone losing its structure — that turned out to be this bug in the probe's own Array.isArray walk, not a structuredClone defect.

[proggeramlug]

Upgrade: this is a false POSITIVE as well as a false negative, and the answer comes from the binding's initializer rather than from the value.

Enumerating the arms instead of trusting the one spelling I first hit:

initializer	reassigned to	perry	node
0	array	false	true
"s"	array	false	true
{}	array	true	true
null	array	false	true
undefined	array	true	true
[9]	array	true	true
[9]	0	true	false
[9]	"s"	true	false
const c: any = [1] (no reassign)	—	true	true

The result tracks the initializer's static kind, not the runtime value: an array-ish initializer answers true forever, a number/string/null initializer answers false forever. ({} and undefined initializers happen to be correct — those two apparently fall through to the real runtime check rather than being folded.)

So Array.isArray is being constant-folded from a binding proof that assignment never invalidates.

The false-positive direction is the dangerous one, because Array.isArray is overwhelmingly used as a guard:

let v: any = [1, 2, 3];
v = 42;                                  // now a number
if (Array.isArray(v)) {
  console.log("ENTERED", v, typeof v);
  console.log("v.length =", v.length, "v[0] =", v[0]);
  let t = 0; for (let i = 0; i < v.length; i++) t += v[i];
  console.log("sum =", t);
} else { console.log("rejected (correct)"); }

perry 0.5.1464                              node 26.5.1
ENTERED 42 number                           rejected (correct)
v.length = undefined  v[0] = undefined
sum = 0
exit=0                                      exit=0

Perry enters the array branch holding a number and silently produces 0. No throw, no diagnostic, exit 0 — a validation guard passing data it exists to reject.

Scope note: the guard is correct when the value crosses a function parameter (function sum(x: any) { if (!Array.isArray(x)) return -1; … } returns -1 as it should). The stale proof is attached to the local binding, so it does not survive a call boundary.

---

This is the fourth instance today of one root

Not four bugs — one invariant, broken four ways. In every case codegen attaches a kind/representation proof to a local binding, derived from its declaration or its initializer, then uses that proof to pick a specialized lowering or fold a predicate — without invalidating it on reassignment and without checking it is true of the runtime value.

issue	binding proof	what it selected	symptom
#7700	"local is Uint8Array/Buffer" + key node is not a string literal	fold every non-STRING key to Uint8ArrayGet	u8[Symbol.iterator] is a number; a string key held in a local reads a byte
#7796	value's function-ness, lost once stored	inlined truthiness fast path	f ? … falsy while Boolean(f) is true
#7837	declared string on a local that holds a number	concat lowering for +	s + 7 → "427"; t + "x" → "x" (operand dropped)
#7844	initializer's kind, never invalidated by assignment	constant-folded Array.isArray	guard answers from the initializer in both directions

The shared tell, and it is the same sentence in all four: correct inline or at the definition site, wrong once the value lives in a local binding. #7700's recorded tell was already literally "wrong only when STORED in a local".

This is also the predicted failure mode of the representation-selection direction rather than a coincidence — a proof that is sound only where it was derived becomes unsound the moment a later write is not ordered against it, which is structurally the same mistake as the GC rooting-dominance invariant (docs/src/internals/gc-rooting-invariant.md): a proof must dominate every subsequent site that can invalidate it. Here the invalidating site is an assignment rather than a collection point.

Suggest an umbrella over the four with a single acceptance criterion — a binding proof is usable only where it dominates every write to that binding, and a proof derived from a declared TS type is not a proof at all without a runtime check — rather than four independent patches, since patching one spelling at a time is what let the same root ship four times.

[proggeramlug]

Rolled up into #7846 — this is one of four instances of a single root: a type/kind proof attached to a local binding, used at sites that a later write to that binding does not dominate. The shared tell across all four is "correct inline or at the definition site, wrong once the value lives in a local". #7846 argues for a detector rather than four independent patches.