Allowing subclasses to narrow types from the superclass breaks substitutability

[bicknellr]

Bug Report

🔎 Search Terms

• liskov
• liskov substitution
• substitution
• subclass narrow
• subclass substitution

🕗 Version & Regression Information

• This is the behavior in every version I tried (all that are available on the playground currently) and I reviewed the FAQ for entries about substitutability. (I'm not sure if the "Why are function parameters bivariant?" section is relevant to this situation.)

⏯ Playground Link

• instance method snippet
• static function snippet

💻 Code

class A {
  f(p: string | number) {
    console.log('A', p);
  }
}

class B extends A {
  f(p: string) {
    console.log('B', p, p.charCodeAt(0));
  }
}

const arrayOfA: Array<A> = [new A(), new B()];
for (const item of arrayOfA) {
  item.f(123);
}

Also:

class A {
  static f(p: string | number) {
    console.log('A', p);
  }
}

class B extends A {
  static f(p: string) {
    console.log('B', p, p.charCodeAt(0));
  }
}

const arrayOfA: Array<typeof A> = [A, B];
for (const item of arrayOfA) {
  item.f(123);
}

🙁 Actual behavior

TypeScript compiles this code with no error. A runtime error is thrown when B.prototype.f (or B.f) attempts to call .charCodeAt of 123.

🙂 Expected behavior

TypeScript should fail to compile this code, with an error explaining that B may not override f with a function that narrows the type of parameter p.

[bicknellr]

@justinfagnani pointed me to a couple related issues around the static half of this: #5863 #4628

[RyanCavanaugh]

This is exactly method bivariance.

[bicknellr]

I'm not experienced enough with type systems to know if you're using the phrase "method bivariance" to refer to the same thing as the "function parameter bivariance" from the FAQ section or if you're calling out that this is different because this involves a method of a class, rather than some arbitrary function. Do you think this is a valid issue or is this expected behavior?

[RyanCavanaugh]

This is the expected behavior; the widespread prevalence of classes with methods that behave this way (e.g. the DOM event methods, classes with overly strict "compareTo" methods, etc) is why we still have function/method parameter bivariance.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[Woodz]

I strongly recommend that this issue is re-opened and reviewed. This breaks typing of many OOP design patterns (e.g. abstract factory, etc), causing errors that can only be caught at runtime

[RyanCavanaugh]

We're aware of what the implications of this are. See also https://github.com/microsoft/TypeScript/wiki/FAQ#this-is-closed-but-should-be-open-or-vice-versa