How do you type the `ok()` and `err()` constructor helpers of a generic `Result<T, E>` union so a function can return both without annotating T and E at every call site?

## The shape being typed A `Result` type models "success or failure" as a tagged union with two type parameters — one for the success payload, one for the failure payload: ```ts type Result<T, E = Error> = | { ok: true; value: T } | { ok: false; error: E }; ``` The default `E = Error` means `Result<number>` is shorthand for `Result<number, Error>`. Callers then construct values with two helpers rather than writing object literals by hand — and the whole question is how to type those helpers so inference does the work. ## The `never` trick The naive helper takes both parameters: ```ts // don't: E is fixed by no argument, so it falls back to unknown declare function err<T, E>(error: E): Result<T, E>; ``` `T` here is fixed by nothing at the call site. The compiler has no inference source for it, so it lands on `unknown` (or whatever the caller asserts), and the returned value's success branch is useless. The fix is to make each helper generic **only** in the slot its own argument determines and to put `never` in the other slot: ```ts const ok = <T>(value: T): Result<T, never> => ({ ok: true, value }); const err = <E>(error: E): Result<never, E> => ({ ok: false, error }); ``` Why `never` and not `unknown`? Because `never` is the type with no values and is assignable to *every* type, while `unknown` is assignable to almost nothing. Read `Result<number, never>` as "a success carrying a number, whose failure branch cannot occur" — that is literally true of what `ok()` returns, and it is exactly what makes the value fit anywhere a wider `Result` is expected: ```ts function parsePort(raw: string): Result<number, RangeError> { const n = Number(raw); return Number.isInteger(n) && n > 0 ? ok(n) : err(new RangeError(`bad port: ${raw}`)); } ``` Check the assignability member by member. `ok(n)` has type `Result<number, never>`, whose members are `{ ok: true; value: number }` — matching the target's success member — and `{ ok: false; error: never }`, which matches the failure member because `never` is assignable to `RangeError`. `err(...)` has type `Result<never, RangeError>` and passes for the mirror-image reason. No annotations at the call sites, no assertions. Swap `never` for `unknown` and the second half breaks immediately: `unknown` is not assignable to `RangeError`, so the helper's value no longer fits the declared return type and you are back to annotating every call. ## Annotate the function, not the calls The helpers only get you halfway. If you omit the enclosing function's return type, inference gives you the union of whatever the branches produced — a union of two *different* instantiations of `Result`. It is not wrong and it still narrows on the tag, but the signature no longer states one coherent contract, and readers of the public API cannot see which failures are possible. Writing `: Result<number, RangeError>` is the whole discipline: one declared contract, helpers that slot into it silently. When a function can fail in more than one way, widen the error slot with a union — `Result<number, RangeError | SyntaxError>` — and every `err()` call still infers on its own without annotation, because each concrete error type is assignable into the union. ## Carrying the parameters through combinators The same rule governs the operations built on top. A `map` must be generic in the input payload, the output payload, and the error, and must thread the error type through untouched: ```ts function map<T, U, E>(r: Result<T, E>, f: (value: T) => U): Result<U, E> { return r.ok ? ok(f(r.value)) : r; } ``` The failure branch returns `r` itself, already narrowed to the failure member, and the success branch returns `Result<U, never>` — assignable, again thanks to `never`. If you had written the return type as `Result<U, unknown>` or dropped `E` altogether, every caller would lose the error type at the first transformation, which is the usual way these wrappers rot. ## What is not there at runtime None of `T` and `E` survives compilation. A `Result` is a plain object with a boolean tag and one payload field; `ok()` and `err()` are two-line object constructors. The exhaustive handling that the tagged union buys you is a promise about source code the compiler has seen. Data crossing a process boundary — a parsed JSON response claiming to be a `Result` — has to be validated like any other untrusted input before it earns the type.