Experiment with always using parameters from base types for derived methods

[DanielRosenwasser]

Note some related issues for doing this with properties rather than methods: #3667, #6118, #1373.

Goal

We want to make it easier for users to derive types without rewriting the same parameter signature every time

class Base {
  method(x: number) {
    // ...
  }
}

class Derived extends Base {
  method(x) {
    // 'x' should have the type 'number' here.
  }
}

Potential ideas

• Only enable in noImplicitAny (doesn't work for default initializers 😞)
• Revert to any in all locations, opt in with another strictness flag (😞)
• Something else? 😕

Potential issues

Default initializers with more capable derived types

class A {
  a = 1;
}

class B extends A {
  b = 2;
}

class Base {
  method(x: A) {
    // ...
  }
}

class Derived extends Base {
  method(x = new B) {
    x.b;
    // Today, 'x' has type 'B' which is technically unsound
    // but that's just what we do. Does changing this to 'A' break things?
  }
}

Default initializers that become less-capable via contextual types

class Base {
  method(x: "a" | "b") {
    // ...
  }
}

class Derived extends Base {
  method(x = "a") {
    // We have to make sure 'x' doesn't have type '"a"'
    // which is both unsound and less useful.
  }
}

Distinction between properties and methods

Would this work?

class Base {
  method = (x: number) => {
    // ...
  }
}

class Derived extends Base {
  method(x) {
    // Does 'x' have the type 'number' here?
  }
}

What about this?

class Base {
  method(x: number) {
    // ...
  }
}

class Derived extends Base {
  method = (x) => {
    // Does 'x' have the type 'number' here?
  }
}

---

Keywords: base type derived contextual contextually inherit methods implicit any

[sandersn]

Couple of quick observations:

1. Methods have the same implement/override ambiguity that properties do, as discussed in Contextually type implemented properties #6118. The core of any solution to both problems is the balancing of the majority who (I think) want to implement a method strictly against the twin minorities who alternately want to override a method, and those who want to implement a method, but unsoundly. I'm not convinced that restricting the domain to methods helps us choose the right tradeoffs, but it's a good idea to have a discussion since a couple of years have passed.
2. I'm allergic to any function/method syntax distinctions unless everything else works out and there's no way around it. We should start with the assumption that there is no distinction between properties and methods.

[weswigham]

I'm allergic to any function/method syntax distinctions unless everything else works out and there's no way around it. We should start with the assumption that there is no distinction between properties and methods.

I agree - non-explicit syntactic switches are not something I enjoy.

[RyanCavanaugh]

class Base {
  method = (x: number) => {
    // ...
  }
}

class Derived extends Base {
  method(x) {
    // Does 'x' have the type 'number' here?
  }
}

Conveniently, this code is illegal. The converse example would just be a case for #10570

[RyanCavanaugh]

I really want to take this and #10570 as part of a "3.0 is a numerological excuse to make some good breaks" bundle.

Regarding this example

class Base {
  method(x: "a" | "b") {
    // ...
  }
}

class Derived extends Base {
  method(x = "a") {
    // We have to make sure 'x' doesn't have type '"a"'
    // which is both unsound and less useful.
  }
}

I think in any world, Derived#method has the signature (x: string): void. Parameter default expressions have to be widened, and we don't want to contextually type them (i.e. with a literal union type here) because that results in the type of a contextually-typed expression being observable (rules 1 and 2 of contextual typing: don't do that!). And it's certainly legal to write a derived type with a wider method signature than its base, so this code is already quite valid today and it'd be unwise to break it by invalidating anyone calling derived.method("hi")

[donaldpipowitch]

a "3.0 is a numerological excuse to make some good breaks" bundle

Interesting! Are there more breaks in this "bundle"? (Looking for example at #13971)