[thecotne]

Fixes #1700

What

Compiled unions discriminated by typeof, like number | null, number | string or { a: number } | { a: string }, now reject NaN in their number branch, matching number alone and the jitless path:

type("number | null")(Number.NaN) // now ArkErrors: must be a number (was NaN), was NaN

Why

pruneDiscriminant removed the number domain node from the branch matched by switch (typeof data), assuming typeof had already checked it. But that node also carries the NaN check, and typeof NaN is "number", so the "number" case compiled to return true.

When the discriminant is a domain, pruneDiscriminant now keeps a number domain node whose requiresNaNCheck is set. That property was private and is now public, so union.ts can read it. Unit discriminants still prune the domain, since a unit literal implies it. Domains with numberAllowsNaN: true are still pruned as before.

Two discriminant snapshots change as a result:

• discrimination.test.ts, ">2 domain branches": the "number" case is now { domain: "number" } instead of true.
• match.test.ts, "accounts for ordering during discrimination": the { id: number } branch now keeps its id: number check. It no longer appears as an unreachable second branch after an earlier {} branch in the nested kind cases. That removal changes no behavior, because an ordered union always takes the earlier {} branch. Its default case now validates id as a number, so { id: NaN } is rejected there too.

Tests

In ark/type/__tests__/keywords/number.test.ts:

• NaN is rejected by number | null, number | string, number > 0 | null and { a: number } | { a: string }, with JIT and with jitless: true, while valid values still pass.
• A union with a numberAllowsNaN: true domain still accepts NaN.

Checklist:

• Code is up-to-date with the main branch (based on c34bf69)
• You've successfully run pnpm prChecks locally
• There are new or updated unit tests validating the change

Overlap: #1703 (for #1598), which makes number reject Infinity, includes the same pruneDiscriminant change. If that lands first, it covers this bug for the default config. The two changes touch the same lines, so whichever merges second needs a small rebase: keep the Infinity version of the pruneDiscriminant condition, and keep both sets of new tests in number.test.ts.

[pullfrog]

Important

The number | null fix is correct, but the same change makes unions that include an explicit number.NaN unit alongside a number domain reject NaN, while the jitless path still accepts it. type("number.NaN | number | null").allows(Number.NaN) flips from true on main to false here.

Reviewed changes

• DomainNode.requiresNaNCheck is now public — visibility widened from private so union.ts can read it; no runtime change.
• pruneDiscriminant keeps a number domain that requires a NaN check — typescriptType.constraint.subconstraint unions discriminated by typeof (e.g. number | null, number | string) now reject NaN, matching bare number and the jitless path.
• Snapshots updated — discrimination.test.ts ">2 domain branches" now keeps { domain: "number" } for the "number" case; match.test.ts "accounts for ordering during discrimination" now retains the { id: number } check.
• New tests in number.test.ts — cover JIT and jitless for number | null, number | string, number > 0 | null, { a: number } | { a: string }, and a numberAllowsNaN union.

⚠️ Explicit number.NaN units are now dropped from discriminated unions

Unions where the discriminant resolves a number domain and a number.NaN unit into the same typeof "number" case lose NaN acceptance when the NaN unit ends up in the unreachable default case. Before this PR, the pruned-domain shortcut accidentally accepted NaN, so the missing branch was masked; now nothing accepts it. number.NaN | number | string (where the unit is grouped into the "number" case) still works, so the behavior is inconsistent across shapes.

I verified this against both main and the PR head with type.allows (JIT) and type.module(..., { jitless: true }); the inline comment has the repro and root cause.

Technical details

# `number.NaN` unit branch becomes unreachable in discriminated unions

## Affected sites
- `ark/schema/roots/union.ts:1090` — keeping the `number` node here removes the only code path that previously accepted `NaN` for these unions; the `NaN` unit is placed in the `default` case, which is never reached because `typeof NaN === "number"`.
- `ark/type/__tests__/keywords/number.test.ts:65` — the new union tests don't cover a union that contains an explicit `number.NaN` unit.

## Observed behavior (PR head)
```
type("number.NaN | number | null").allows(Number.NaN)        // false  (main: true; jitless: true)
type("number.NaN | number | undefined").allows(Number.NaN)   // false  (main: true; jitless: true)
type("number.NaN | number | string").allows(Number.NaN)      // true
type("number.NaN | number").allows(Number.NaN)               // true  (indiscriminable)
```
`type("number.NaN")` alone allows `NaN`, and `number.NaN | number` is represented as `["number", { unit: "NaN" }]`, so a union that includes the `NaN` unit is expected to accept `NaN`.

`discriminantJson` for the failing shape:
```
{"kind":"domain","path":[],"cases":{
  "\"number\"": {"domain":"number"},
  "\"null\"": {"unit":null},
  "default": {"unit":"NaN"}}}
```
For the passing `| string` shape the `"number"` case is `["number", { "unit": "NaN" }]`, i.e. the unit is folded in.

## Required outcome
- `NaN` is accepted whenever the union contains a branch that accepts it, including when that branch is an explicit `number.NaN` unit, independent of JIT vs jitless.

## Suggested approach (optional)
- Fold a `NaN` unit branch into the `"number"` case during resolution (`resolveCase` / discriminant candidate cases), since its `typeof` key collides with the `number` domain case.
- Alternatively, in `pruneDiscriminant` only keep the `number` node when no sibling in the same case already accepts `NaN`.

## Open questions for the human
- Is this in scope here, or tracked as a separate discriminant-resolution bug? The regression is caused by this PR even though the pre-existing acceptance was accidental.

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

[pullfrog]

Keeping the number node is correct for number | null, but it regresses unions that also contain an explicit number.NaN unit: type("number.NaN | number | null").allows(Number.NaN) returns false here, versus true on main and true with jitless: true. In those unions the NaN unit is resolved into the unreachable default case (its typeof is "number"), so the pruned-domain shortcut this PR removes was the only branch accepting NaN, and now none does.

Technical details

# `number.NaN` unit branch becomes unreachable in discriminated unions

## Affected sites
- `ark/schema/roots/union.ts:1090` — this condition removes the only accepting path; the `NaN` unit sits in an unreachable `default` case.
- `ark/type/__tests__/keywords/number.test.ts:65` — add a case with an explicit `number.NaN` unit in the union.

## Repro (PR head)
```
type("number.NaN | number | null").allows(Number.NaN)        // false (main true, jitless true)
type("number.NaN | number | undefined").allows(Number.NaN)   // false (main true, jitless true)
type("number.NaN | number | string").allows(Number.NaN)      // true (unit folded into "number" case)
```
`discriminantJson`: `{"kind":"domain","path":[],"cases":{"\"number\"":{"domain":"number"},"\"null\"":{"unit":null},"default":{"unit":"NaN"}}}`.

## Required outcome
- `NaN` accepted whenever the union has a branch accepting it, including an explicit `number.NaN` unit, matching `jitless`.

## Suggested approach (optional)
- Fold the `NaN` unit into the `"number"` case during resolution, or only keep the `number` node when no sibling in the same case accepts `NaN`.

## Open questions for the human
- In scope here, or a separate discriminant-resolution follow-up?

[ssalbdivad]

thanks @thecotne, nice catch! added a small follow-up so an explicit number.NaN branch still gets routed to the right case, then merged