Method vs Property Function Typing

## What the two rules are Assignability between function types comes down to two questions: can the target's return type be produced, and can the target's parameters be accepted? - **Return types are covariant**, always. A function returning `Dog` is assignable where a function returning `Animal` is expected, because every value it hands back is a valid `Animal`. - **Parameters are the interesting half.** The sound rule is **contravariance**: a function is only safe as a replacement if it accepts *everything* the declared type promised callers could pass. So `(e: Event) => void` is assignable to `(e: MouseEvent) => void` — it copes with more — but not the other way round. TypeScript applies the sound, contravariant rule only when `strictFunctionTypes` is enabled (it is part of the `strict` family), and only to function types that did **not** originate in a method or constructor declaration. Everything else — method shorthand in an interface, object type or class, and constructor signatures — is compared **bivariantly**: the check passes if the parameters are assignable in *either* direction. ## Walking the example ```ts interface MethodForm { handle(e: Event): void } interface PropForm { handle: (e: Event) => void } const a: MethodForm = { handle(e: MouseEvent) { console.log(e.clientX); } }; // OK: bivariant — MouseEvent is assignable to Event, so the relation passes. // const b: PropForm = { handle(e: MouseEvent) {} }; // Error 2322: contravariant — Event is not assignable to MouseEvent. ``` For `a`, the target member `handle` is a method signature. The checker sees a method declaration on the target and skips the strict variance path, so it accepts the pair as long as one direction works. `MouseEvent extends Event`, so one direction works, and the assignment compiles. For `b`, the target member is a property signature whose type happens to be a function type. No method declaration is involved, so `strictFunctionTypes` applies the contravariant rule and the assignment fails. ## The target declaration is what decides A common misreading is that the *implementation's* syntax matters. It does not. In the `b` case the source is written with method shorthand (`{ handle(e: MouseEvent) {} }`) and it is still rejected, because the declared type it is being checked against uses the property form. If you want the loose check, the *declared* type has to be the method form. Practically, this means the author of the interface — not the author of the implementation — chooses how strictly callbacks get checked. ## Why the loose rule exists at all Bivariant methods are a deliberate concession. Making method parameters contravariant would immediately break generic container types: `Array<T>` declares `push(...items: T[]): void`, `indexOf(searchElement: T): number` and friends, all of which put `T` in a parameter position. Under a contravariant rule, `Dog[]` would no longer be assignable to `Animal[]`, and an enormous amount of ordinary, mostly-correct code would stop compiling. TypeScript chose usability over soundness here and documents it as such. ## The hole it leaves The hole is real and worth demonstrating in an interview: ```ts const a: MethodForm = { handle(e: MouseEvent) { console.log(e.clientX); } }; a.handle(new KeyboardEvent("keydown")); // type-checks; clientX is undefined ``` Every caller of `a` is entitled by the type to pass any `Event`. The implementation assumed a `MouseEvent`. Nothing at runtime enforces the difference, because types are erased. The failure is not a `TypeError` at the boundary — it is a silently `undefined` property, or a crash several frames deeper. ## What to do about it - Declare callbacks that consumers supply as **property function types**, so a narrower parameter is a compile error at the point where it is written. - Keep **method shorthand** where the type is container-like or where many implementers legitimately vary the parameter type, and accept that you are trusting them. - If a handler really only wants a subset, take the wide type and narrow inside the body with a guard such as `if (e instanceof MouseEvent)`. That produces a check that actually exists at runtime, rather than a promise the compiler cannot keep. - Turning `strictFunctionTypes` off returns *everything* to bivariance, which is strictly worse; the flag is not the source of the problem.