Fix #186: every arm of a views module gets both doors, not just the nameable ones

[jagguji]

Closes #186.

The bug in one line

A views module emits from<X> (put a value in) and, since #122, as<X> (read one back out). The constructor name falls back to the arm's kind when there's no name hint; the reader gate had no fallback. Two sources for one decision, so they disagreed:

// src/emit.mjs:914 — constructor: hint, ELSE fall back to the kind
const fromName = (m) => m.name ? 'from' + pascalName(m.name)
    : 'from' + titleCase(… m.type.res || m.type.kind || 'value')   // fromArray, fromNumber

// src/emit.mjs:969 (before) — reader: structured kind OR hint, no fallback
if (m.type.kind === 'typeRef' || … || m.name) { … }

An arm with a constructor but no derivable hint got a one-way door.

Why it's a bug and not a policy

The split tracked naming, not soundness, and it produced distinctions nobody would defend:

arm	reader before?	why
string[]	no	primitive element — nothing to build a hint from
string[][]	yes	TS names the inner element Array, so a hint existed
number	no	no hint
boolean	yes	opaqueUnion hard-codes name: 'Bool'

string[] having no reader while string[][] has one is the give-away. Nothing about safety separates them: asArray: t => array<string> is exactly as unchecked as the asNamedA next to it, and both require the caller to establish the arm first — which is this module's contract either way.

The consumer cost this closes

Highcharts, real and in the baselines:

export type ColorString = string;
export type ColorType = (ColorString | GradientColorObject | PatternObject);

ColorType.t is returned by the library — HighchartsSharedTypes.res:2550, get: option<string> => ColorType.t, i.e. Highcharts.color("#ff0000").get() — and what comes back is almost always the plain string. Before:

let c = someColor.get(None)          // holds "#ff0000"
c->ColorType.asGradientColorObject   // compiles. WRONG — reads a string as a record
c->ColorType.asString                // ✗ didn't exist

There was no way to get the string back out, and the only thing that compiled was a reader for the wrong shape — silently, since these are zero-cost %identity views with no runtime check. ColorType.t appears 1085 times in blend's bindings.

The fix

Make the reader gate mirror fromName rather than re-derive the arm's identity — every arm reaching the generic from* branch gets both doors. This deletes a special case instead of adding one. Arms that legitimately need no reader (tagSet, literal, none) each are their own runtime value and already continue above the gate.

 module ColorType = {
   type t
   external fromString: string => t = "%identity"
+  external asString: t => (string) = "%identity"
   external fromGradientColorObject: gradientColorObject => t = "%identity"
   external asGradientColorObject: t => (gradientColorObject) = "%identity"

 module ChartsSonificationSpeechMappingOptionsPitch = {
   external fromString: string => t = "%identity"
+  external asString: t => (string) = "%identity"
   external fromNumber: float => t = "%identity"
+  external asNumber: t => (float) = "%identity"

One deliberate exclusion, now principled where the old one was incidental: a type-variable arm keeps fromTypeVar and gets no reader, because as…: t => 'a unifies with any type at the call site — a universal unsafe cast, not a view of one arm. base-ui's RootFilteredItems (readonly any[] | readonly Group<any>[]) is the real instance, and the fixture reproduces it.

Measured, then reconciled exactly

53 of 1624 views modules across the baselines had a reader-less arm; 42 were the string | number | record shape. Counting individual missing readers predicted 96; the fix adds 95, and the 1 remainder is the excluded typeVar arm.

Baseline diff: 95 insertions, 0 deletions or modifications, 6 files. No existing declaration changes, so — unlike #185 — no rename churn. No metrics.json moved: this adds capability without reclassifying anything.

Teeth, verified in both directions

Broke it two ways to confirm the fixture actually fails:

• revert to the old name-hint gate → 2 cases fail (views-module-readers, record-props)
• drop the typeVar exclusion → 1 case fails (views-module-readers)

The fixture carries the string[] vs string[][] pair on purpose, so a future change re-coupling the reader to the name hint makes them diverge again and fails. It also pins the typeVar exclusion in a golden, not only in the benchmark — the benchmark is an opt-in gate that a wholesale "emit readers unconditionally" simplification would sail past.

Verification

• npm test — smoke + 113 goldens match
• npm run test:compile — 113/113 compile on ReScript
• npm run bench — 10/10 identical to (updated) baselines
• docs/TYPE_MAPPING.md — "Opaque-module unions" section updated; the old text said "every structured arm"

🤖 Generated with Claude Code

[github-actions]

Benchmark: ✅ PASS

Package	Compile	Diff vs baseline	usable	review	broken	Verdict
@juspay/blend-design-system@0.0.36	✅	identical	102	5	0	✅ PASS
@juspay/blend-design-system@0.0.37-beta.8	✅	identical	215	7	0	✅ PASS
@juspay/blend-design-system@0.0.37	✅	identical	219	7	0	✅ PASS
react-day-picker@10.0.1	✅	identical	19	7	0	✅ PASS
react-tooltip@6.0.7	✅	identical	1	0	0	✅ PASS
react-markdown@10.1.0	✅	identical	0	2	0	✅ PASS
@smastrom/react-rating@1.5.0	✅	identical	1	0	0	✅ PASS
clsx@2.1.1	✅	identical	0	0	0	✅ PASS
hono@4.12.25	✅	identical	0	0	0	✅ PASS
@base-ui-components/react@1.0.0-rc.0	✅	identical	174	21	0	✅ PASS

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@juspay/rescript-bindgen@187

commit: a5b89a4