[ybai08]

A tuple's defaultables become optionals on input and prefix elements on output, but the defaultables reduceIo assigned them over inner.optionals / inner.prefix instead of combining them with what the prefix and optionals children had already written (or would write next, depending on key order). Either the defaultable elements or the elements around them were lost:

const T = type(["string", "number = 5", "boolean?"])
T.in.expression // "[string, boolean?]", so T.in.allows(["", true]) is true
// expected "[string, number?, boolean?]"

const V = type(["number", "string = 'foo'", "...", "number[]"])
V.out.expression // "number[]"
// expected "[number, string, ...number[]]"

The inferred types (T.inferIn, V.inferOut) were already right; only the runtime nodes were wrong.

prefix, optionals and defaultables now each have a reduceIo that combines with what's already there in tuple order (prefix, then defaultables on output; defaultables, then optionals on input), so the result doesn't depend on which key is reduced first. This follows the same pattern as required/optional in structure.ts.

Related: type(["number", "string = 'foo'"]).out currently throws Unexpectedly encountered multiple distinct intersection results for refinement Type<>= 2>. That one also needs the intersection fix in #1697, because the output's exactLength of 2 has to be reduced against the original minLength: 1 / maxLength: 2. With both changes it gives [number, string]. I kept them separate since they're independent bugs.

Tests

Added to ark/type/__tests__/arrays/defaults.test.ts:

• [string, number = 5, boolean?]: .in and .out types, expressions and allows
• [number, string = 'foo', ...number[]]: .in and .out expressions

Both fail on main and pass with this change.

What was run locally:

• pnpm testFiles ark/type/__tests__/arrays/defaults.test.ts (with type assertions): 11 passing
• pnpm test: 1793 passing
• pnpm typecheckRepo: no errors
• prettier --check and eslint on the changed files: clean

Not run: the full pnpm prChecks (buildRepo, benches, testV8, testIntegration, testTsVersions, testTypedLoose).

[pullfrog]

✅ No new issues found.

Reviewed changes — verified the tuple reduceIo composition fix and its regression tests against main (c34bf69).

• Tuple reduceIo composes instead of overwriting — prefix, optionals, and defaultables now merge into inner.prefix/inner.optionals in tuple order (prefix then defaultables on output; defaultables then optionals on input), so elements adjacent to a default are no longer dropped. The order-independence claim holds: prefix prepends, defaultables prepends on in/appends on out, and optionals appends, so any key reduction order yields the same result.
• Regression tests — [string, number = 5, boolean?] and [number, string = 'foo', ...number[]] assert .in/.out expressions, inferred types, and allows.

I reproduced the bug on the base commit (e.g. .in/.out both yielded [string, boolean?] for the first case, and .out collapsed to number[] for the second) and confirmed both are corrected. The ["number", "string = 'foo'"].out throw mentioned in the description is genuinely pre-existing — it throws on base too (with a <= 1 refinement message), so this PR does not introduce it. No regressions in the full suite (1793 passing).

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[ssalbdivad]

thanks @ybai08! merged this together with your #1697 since they depend on each other. also trimmed the merges inside defaultables, since keys always reduce in sorted order so those never ran