Method Bivariance & Strict Function Types

The plain-language idea

strictFunctionTypes (one of the flags bundled into strict) makes function parameter types check contravariantly: a function expecting a narrower type isn't safely substitutable where a function expecting a wider type is required. That's the theoretically correct rule, and for most function-typed values, TypeScript enforces it strictly.

Except for one specific case: method shorthand syntax inside an interface or type — foo(x: Dog): void instead of foo: (x: Dog) => void. Method shorthand is checked bivariantly — more leniently, in both directions — even under strictFunctionTypes. Same signature, same meaning, genuinely different strictness, depending purely on which syntax you used to write it.

See it in a real thing: identical signatures, different checks

interface Animal { name: string }
interface Dog extends Animal { bark(): void }

interface Handler {
  handle(a: Animal): void;          // method shorthand — checked bivariantly
  handleStrict: (a: Animal) => void; // function-typed property — checked contravariantly
}

const dogHandler: Handler = {
  handle(d: Dog) {
    d.bark();
  },
  handleStrict: (d: Dog) => {       // ❌ error under strictFunctionTypes:
    d.bark();                       //    Dog is narrower than Animal, not assignable here
  },
};

handle accepts an implementation that only knows how to deal with Dog, even though the interface promises any Animal. handleStrict, with the exact same effective signature, gets rejected for doing the same thing. The difference is entirely about which of the two equivalent syntaxes was used to declare the member.

What people usually miss

Watch out

• Bivariance is a deliberate escape hatch, not a bug report waiting to happen. Without it, extremely common real-world patterns — a subclass overriding a method with a narrower parameter type than its base class declares — would be nearly impossible to express without excessive generics or type assertions everywhere.
• The leniency is tied to the syntax, specifically. handle(a: Animal): void and handleStrict: (a: Animal) => void describe the exact same call signature. Only the shorthand form gets the bivariant check; the moment the identical signature is written as a property holding a function type, strictFunctionTypes applies in full.
• This is exactly why library authors reach for method shorthand in callback-heavy interfaces on purpose — it's a conscious substitutability choice, not an oversight, when they want implementers to be able to accept narrower parameter types.
• Bivariance only affects parameter checking. Return type checking is unaffected either way — it's always covariant, for both method shorthand and function-typed properties equally.

Why this matters in interviews

strictFunctionTypes is one of the flags bundled into "strict": true, covered elsewhere in this track, so this is a concrete example of what that specific flag actually changes. It's also a genuine carve-out from ordinary structural typing — the usual "does this shape have everything required" comparison gets deliberately relaxed for method shorthand specifically, and being able to explain why (not just that it happens) is a real signal of depth beyond "I've seen this error before."