Use an implemented interface's types on class members implicitly

[martaver]

🔍 Search Terms

"interface member types in classes", "re-use interface types in classes "

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

In class members that implement an interface's members, when no types are explicitly defined TS should implicitly use the types defined in the interface.

This is line with the following design goal of Typescript:

• Produce a language that is composable and easy to reason about.

📃 Motivating Example

I've always wondered why an interface's types aren't implicitly used in classes that implement them, e.g.

interface IFoo { foo(args: { value: Date }): string }

class Foo implements IFoo {
  foo(args) { // <-- method argument type is 'any'
    throw new Error('Method not implemented.');
  }
}

Instead, classes require us to re-declare the types for class members, causing unnecessary duplication.

The role of an interface is to define a contract for behaviour, so it seems reasonable to assume that, unless explicitly defined otherwise, the members a class implements from an interface should implicitly be those that are defined already in the interface.

💻 Use Cases

1. What do you want to use this for?

• Eliminate the need to duplicate an interface's types when implementing them in a class
• Allow interfaces be the single source of truth / documentation for an interface's types, unless explicitly narrowed / widened by the class.

3. What shortcomings exist with current approaches?

• When refactoring, changing an interface's type signature may not be immediately reflected in classes that implement it, because each implementation must explicitly declare their own type signatures. Because of this, the material changes required by the refactoring aren't surfaced until each implementing class' type defs are updated. It's just more work that probably doesn't need to exist.

5. What workarounds are you using in the meantime?

• I use the Parameters and ReturnType types to annotate class methods with the types from an Interface and modify them as necessary. Here's a naive example:

interface IFoo { foo(args: { value: Date }): string }

class Foo implements IFoo {
  foo(...args: Parameters<IFoo['foo']>): ReturnType<IFoo['foo']> { // <-- method argument type is 'any'
    throw new Error('Method not implemented.');
  }
}

This is nice, because changing the type signature in the interface immediately surfaces problems in the method's implementation, but it's very wordy and repetitive.

[MartinJohns]

Duplicate of #32082.

[martaver]

Closing in favour of: #32082.