In the last lesson you wrote sortByTotal(orders) and TypeScript worked out that T was DetailedOrder. Most of the time inference does what you want, which makes the times it does not feel random. They are not. TypeScript follows a small set of rules, and once you know them you can design signatures that infer exactly the type you intend, with no <…> at the call site.
Every place a type parameter appears inside a parameter’s type is an inference site. At a call, TypeScript matches each argument against its parameter type and collects a candidate for the type parameter from each site. Then it picks one type from the candidates.
\nfunction same<T>(a: T, b: T): T[] {\n return [a, b];\n}\n\nsame('processing', 'shipped'); // T = string, so string[]\nsame(1, 'a');\n// Error: Argument of type 'string' is not assignable to parameter of type 'number'.With two string literals, the candidates 'processing' and 'shipped' are combined and then widened to string, because T is only returned inside an array (the next section explains when literals survive). With 1 and 'a', TypeScript does not invent number | string; it picks the first candidate, number, and then the second argument fails against it. That is deliberate. Silently widening to a union would hide the bugs generics are meant to catch. If you really want mixed values, say so: same<number | string>(1, 'a').
The second rule explains most “why did I get string?” moments. A literal candidate like 'processing' is kept or widened depending on the signature:
function identity<T>(value: T): T { return value; }\nfunction box<T>(value: T): { value: T } { return { value }; }\nfunction boxStatus<T extends string>(value: T): { value: T } { return { value }; }\n\nconst a = identity('processing'); // 'processing'\nconst b = box('processing'); // { value: string }\nconst c = boxStatus('processing'); // { value: 'processing' }The literal survives when T is returned directly at the top level (identity), or when T’s constraint includes a primitive type such as string (boxStatus). Otherwise it widens, on the theory that a value tucked into an object will probably be reassigned later.
Objects follow the same logic, and here a constraint has a second benefit: it gives the argument a contextual type.
\ntype OrderStatus = 'processing' | 'shipped' | 'delivered' | 'cancelled' | 'returned';\n\nfunction draft<T>(order: T): T { return order; }\nfunction draftOrder<T extends { status: OrderStatus }>(order: T): T { return order; }\n\ndraft({ status: 'processing' }); // { status: string }\ndraftOrder({ status: 'processing' }); // { status: 'processing' }Because the constraint says status is an OrderStatus, TypeScript checks the literal against that union while inferring, and the literal type sticks. A good constraint both documents the function and improves what it infers.
Sometimes you want the caller’s argument exactly as written: tuple order, literal values, nested objects. Before TypeScript 5.0 that meant asking every caller to write as const. Now the function can ask for it:
function defineFlow<const T extends readonly OrderStatus[]>(steps: T): T {\n return steps;\n}\n\nconst happyPath = defineFlow(['processing', 'shipped', 'delivered']);\n// readonly ['processing', 'shipped', 'delivered']The const modifier tells TypeScript to infer the argument as if it had as const: literals stay literal, arrays become readonly tuples, object properties become readonly. Pair it with a readonly array constraint, since as const produces readonly arrays. It only affects literals written directly in the call; a variable you pass in keeps whatever type it already had.
Arguments that are functions with unannotated parameters, such as (d) => d.totalCents, are context-sensitive: their parameter types come from the signature, which may still depend on T. TypeScript infers from everything else first, then types these callbacks. Inside a single object literal, it works through context-sensitive properties from left to right:
function createStep<T>(config: { load: (orderId: number) => T; render: (data: T) => string }) {}\n\ncreateStep({\n load: (orderId) => ({ orderId, totalCents: 4500 }),\n render: (d) => d.totalCents.toFixed(), // d: { orderId: number; totalCents: number }\n});\n\ncreateStep({\n render: (d) => d.totalCents.toFixed(), // Error: 'd' is of type 'unknown'.\n load: (orderId) => ({ orderId, totalCents: 4500 }),\n});When render comes first, T has no candidate yet. You can fix it at the call site by swapping the properties or annotating orderId: number, which makes load no longer context-sensitive. Better, fix it in the API: put the producer before the consumer in your parameter lists and documented examples, so the natural way to call it is the way that infers.
In the exercise you will make three Cartwheel helpers keep the literals their callers pass. Next, you will learn to stop inference from happening where it should not.
\n","toc":[{"id":"sec-1","text":"Inference sites and candidates","level":2},{"id":"sec-2","text":"When literals widen","level":2},{"id":"sec-3","text":"const type parameters","level":2},{"id":"sec-4","text":"Callbacks are inferred last","level":2}],"takeaways":["Every place a type parameter appears in a parameter type is an inference site; TypeScript collects a candidate from each argument and picks one type.","Inferred literals widen unless the type parameter’s constraint includes a primitive type or the parameter is declaredconst.","A const type parameter infers arguments as if they were written with as const, keeping literals and readonly tuples without asking the caller.","Callbacks with unannotated parameters are inferred after other arguments, and inside one object literal TypeScript works left to right.","Explicit type arguments are all or nothing; specify one and TypeScript stops inferring the rest."],"further":[{"title":"Type Inference","url":"https://www.typescriptlang.org/docs/handbook/type-inference.html"},{"title":"const type parameters (TypeScript 5.0 release notes)","url":"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html"}],"quiz":[{"q":"What is the type of b?
function box<T>(value: T): { value: T } { return { value }; }\nconst b = box('processing');{ value: 'processing' }","why":"That is what you would get with T extends string or a const type parameter. An unconstrained T nested in the return type widens."},{"text":"{ value: string }","why":"Correct. The literal candidate widens because T has no primitive constraint and is not returned at the top level."},{"text":"{ value: unknown }","why":"unknown is what TypeScript falls back to when it finds no candidate at all. Here it found one: the string argument."}],"answer":1},{"q":"Which declaration makes defineFlow(['processing', 'shipped']) return the type readonly ['processing', 'shipped'] without the caller writing as const?
function defineFlow<T>(steps: T[]): T[]","why":"This infers T as string and returns string[]; the order and the literals are both lost."},{"text":"function defineFlow<T extends string>(steps: T[]): T[]","why":"The constraint keeps the literals, but you get the array type ('processing' | 'shipped')[], not a readonly tuple."},{"text":"function defineFlow<const T extends readonly string[]>(steps: T): T","why":"Correct. The const modifier infers the argument as if it had as const, so you get a readonly tuple of literals."},{"text":"function defineFlow(steps: readonly string[]): readonly string[]","why":"Without a type parameter there is nothing to capture the argument’s precise type."}],"answer":2},{"q":"Why is d typed as unknown here?
createStep({\n render: (d) => d.totalCents.toFixed(),\n load: (orderId) => ({ orderId, totalCents: 4500 }),\n});render comes before load, and TypeScript infers context-sensitive functions in an object literal from left to right.","why":"Correct. When render is checked, T has no candidate yet. Put load first, or annotate orderId so load is not context-sensitive."},{"text":"Because T cannot be inferred from a return type.","why":"It can; load’s return type is the inference site for T. The problem is when that site is visited."},{"text":"Because arrow functions in object literals disable inference.","why":"Inference works fine in object literals; swapping the two properties makes this compile."}],"answer":0},{"q":"function convert<From, To>(value: From, to: (v: From) => To): To is called as convert<string>('12', Number). What happens?
To is inferred as number from Number.","why":"TypeScript does not do partial inference. Once you pass any explicit type argument, it expects all of the required ones."},{"text":"It is an error, “Expected 2 type arguments, but got 1”.","why":"Correct. Explicit type arguments are all or nothing, unless the remaining parameters have defaults."},{"text":"To becomes unknown, and the call compiles.","why":"Missing type arguments only fall back silently when they have defaults. Without one, the call is rejected."}],"answer":1}],"exercise":{"kind":"web","mode":"ts","starter":{"ts":"type OrderStatus = 'processing' | 'shipped' | 'delivered' | 'cancelled' | 'returned';\ntype Flag = { rollout: number; countries: readonly string[] };\n\nfunction defineFlow(steps: OrderStatus[]) {\n return steps;\n}\n\nfunction oneOf(values: readonly string[]) {\n return (input: string): boolean => values.includes(input);\n}\n\nfunction defineFlags(flags: RecordThree definition helpers in Cartwheel’s checkout lose the precise types their callers write. Make the type tests pass without changing the calls (no as const at the call sites):
defineFlow(steps) returns the steps as a readonly tuple of literal statuses, and still rejects unknown statuses.oneOf(values) returns a type guard: after if (isChannel(raw)), raw is narrowed to the literal values passed in.defineFlags(flags) keeps each flag’s exact shape (including the countries tuple) while still checking every flag against Flag.All three return their argument unchanged at runtime (oneOf returns a checking function).
const type parameter infers the argument as if the caller had written as const.","Give each function a type parameter whose constraint is the old parameter type, for example <const T extends readonly OrderStatus[]>(steps: T): T.","For oneOf, the returned function’s return type is a type predicate: (input: string): input is T[number] => …. Inside, widen the tuple for includes: (values as readonly string[]).includes(input)."],"explanation":"Without a type parameter, each function’s return type is just its parameter annotation, so the literals the caller wrote are gone. A const type parameter captures the argument with as const semantics: tuples stay ordered and readonly, strings stay literal. The constraint (extends readonly OrderStatus[], extends Record<string, Flag>) still validates the argument, so 'refunded' and a flag without rollout are rejected. In oneOf, T[number] is the union of the tuple’s elements, and the type predicate hands that union to the caller’s if.
oneOf returns a function that accepts only the listed values","identity":"defineFlow and defineFlags return their argument unchanged"}},"words":722,"readMinutes":3}