Generics

It produces string. keyof T is the union of T's property names, so K is constrained to those names and infers the literal 'name' at this call; the return type T[K] then resolves to that one property's type.

A type-parameter default supplies the type argument when the caller omits it, so writing ApiResult with no argument means ApiResult<unknown>. TypeScript also falls back to the default in a generic call when inference finds no candidate for that parameter.

A type parameter links the argument type to the return type, so the call site keeps the concrete type it passed in and stays type-checked. any turns checking off instead: the result is unchecked and any misuse of it silently compiles.

The <T> declares a type parameter: a placeholder the user of the interface fills in. Writing ApiResponse<User[]> substitutes User[] for T everywhere in the declaration, so res.data has type User[] while status stays number.

first([1, 2, 3]) has type number | undefined. TypeScript matches the argument type number[] against the parameter type T[] at the call site, infers T as number, and substitutes that into the declared return type.

Returning T preserves the caller's exact type, so extra properties survive the call. Returning the constraint widens every result to { id: string } and silently discards the rest. Prefer T — carrying the caller's type through is the reason the generic exists.

Giving the key its own type parameter captures which key was passed. With key: keyof T the compiler only knows it was some key, so the return type T[keyof T] is the union of every property type, and the caller must narrow it back down.

A function expression written directly in an argument position is contextually typed: its parameter types come from the expected callback type. A standalone const has no such context, so its parameter is an implicit any error under strict.

Nothing. T appears only in the return type, so there is no inference site and the caller simply picks it — an unchecked assertion, equivalent to as User. Return Promise<unknown>, or take a validator parameter so T is derived from real runtime code.

Declare the type parameter on the component function and thread it through the props: function List<T>(props: { items: T[]; renderItem: (item: T) => ReactNode }). TypeScript infers T from the items passed at each usage site.

Box<T> is covariant because T only appears in an output position, so Box<Dog> is assignable to Box<Animal>. Sink<T> is contravariant because T appears only as a parameter, so Sink<Animal> is assignable to Sink<Dog>.

TypeScript compares parameters of members declared with method shorthand bivariantly, so the narrower MouseEvent parameter is accepted. The property form is a plain function type, and strictFunctionTypes, which strict enables, compares those parameters contravariantly, making the narrowing an error.

A type parameter earns its place only when it links two positions in a signature. getFirst returns T, so it carries the element type back to the caller; getLength never uses T again, so it should just take unknown[].

In .tsx files the parser reads the leading angle bracket as the start of a JSX element, not a type parameter list. Disambiguate with a trailing comma, <T,>, add a constraint such as <T extends unknown>, or use function syntax.

Neither form emits anything: interfaces are erased, so the JavaScript is identical. They are not fully interchangeable to the checker, which compares method-shorthand parameters loosely in both directions but compares a property function type's parameters strictly under strict mode.

object means non-primitive, so arrays, functions and class instances pass while strings and numbers are rejected. {} means anything except null and undefined, so primitives pass. unknown constrains nothing at all — it is the same set as an unconstrained parameter.

Inside the function T is still unresolved, so T[K] is a deferred type the checker cannot prove is number, and arithmetic on it is rejected. Fix it by relating the parameters the other way: constrain the object to a Record whose value at the key is number.

Defaults must come last: once a type parameter has one, every later parameter needs one too. A default may reference parameters declared before it but not after, and when the parameter is also constrained the default must itself satisfy that constraint.

No. TypeScript has no partial type-argument inference: a call supplies every type parameter that has no default, or none at all. Omitted trailing parameters take their declared defaults rather than being inferred from the arguments.

Position decides who picks T. In the first, the type takes no arguments and describes a generic function whose T is chosen fresh at each call. In the second, the type itself takes an argument and describes an ordinary non-generic function.

In .tsx files the parser reads <T> as the opening tag of a JSX element, not a type parameter list, so the line never parses as a generic arrow. Disambiguate with a trailing comma, <T,>, with a constraint, or by using a function declaration.

A class type parameter is decided once, when the class is instantiated or annotated, and stays fixed for that instance type, so the field and the method share it. Moving it onto the method makes it fresh at every call, breaking that link to the stored items.

TypeScript reports that static members cannot reference class type parameters. Statics live on the single constructor object shared by every instantiation, so there is no one T for them. Give the static its own type parameter instead.

It makes inference treat the argument as if the caller had written a const assertion: object literals come back with readonly literal-typed properties, arrays as readonly tuples. It affects only expressions written at the call site, and nothing at runtime.

TypeScript infers the fresh literal type "red" and then widens it to string, because nothing in the signature asks for a literal. Constraining the type parameter with T extends string, or marking it const, preserves the literal.

TypeScript collects one candidate per inference site and keeps the candidate that is a supertype of the others, so pair(animal, dog) gives Animal[]. When no candidate covers the rest, pair(1, "x") is a compile error rather than a silent union.

With no argument mentioning T, inference has nothing to work from: T falls back to its constraint when it has one. So make() gives unknown, while makeStr() with T extends string gives string.

In that exact shape the generic is pure noise — both signatures accept identical arguments, because T is used once. A constrained type parameter only earns its keep when another parameter or the return type is expressed in terms of T.

Make the builder generic in what it has accumulated so far and have each chaining method return a new instantiation, such as Builder<T & Record<K, V>>, rather than Builder<T>. Returning the same type throws away whatever the call just added.