Repository: TypeScript
Issue: Show completions based on type of inherited / overridden field or method
Labels: Suggestion,Domain: Completion Lists,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

*TypeScript Version*: v5.0.4, tested in TypeScript playground

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

* typescript intellisense for overriden method
* typescript intellisense extend interface
* typescript completion for inherited field

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

Below, I will use `❌` to indicate the location where intellisense fails to show the expected result.

### Scenario 1:  Class Overrides Method from Interface

In the code below, there are no intellisense hints available to help fill in the required values for the return type `{ x: number, y : number}` of `getLocation`.

```typescript
interface HasLocation {
  getLocation(): { x: number, y: number }
}

class City implements HasLocation {
  getLocation() {
    return {
      ❌ // no suggestions available
    }
  }
}
```

I would expect the suggestions to include `(x:number), (y:number)`.

### Scenario 2:  Class Overrides Field from Interface

```typescript
interface HasLocation {
  location: { x: number, y: number }
}

class City implements HasLocation {
  location = { ❌ /* no suggestions available */ }
}
```

I would expect the suggestions to include `(x:number), (y:number)`.

### Scenario 3:  Class Overrides Method from Abstract Class

```typescript
abstract class HasLocation {
  abstract getLocation(): { x: number, y: number }
}

class City extends HasLocation {
  override getLocation() {
    return {
      ❌ // no suggestions available
    }
  }
}
```

I would expect the suggestions to include `(x:number), (y:number)`.

### Scenario 4:  Class Overrides Field from Abstract Class

```typescript
abstract class HasLocation {
  abstract location: { x: number, y: number }
}

class City extends HasLocation {
  location = { ❌ /* no suggestions available */ }
}
```

I would expect the suggestions to include `(x:number), (y:number)`.

### Working Scenario:  Interface Instance

By comparison, if we declare a variable to have type `HasLocation`, intellisense works as expected:

```typescript
interface HasLocation {
  getLocation(): { x: number, y: number }
}

const origin: HasLocation = {
    getLocation() {
        return {
            // ✅ suggestions: (x:number), (y:number)
        }
    }
}
```

## 📃 Motivating Example

See the scenarios above.  This feature would make it easier for users of a library to correctly implement interfaces and extend abstract classes exposed by the library, without the need to directly check the documentation. 

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

I ran into this issue while building a "community plugin" system for a TypeScript library.  The idea is:

* the library will define an `Extension` interface (or abstract class)
* extension authors make a `class CustomExtension implements Extension` (or `class CustomExtension extends Extension`), with rich intellisense hints available for filling in the required values

If needed I can provide further details about the motivation, but I think the scenarios above are already clear enough.  As a workaround, for now, I can structure my code similar to the "Working Scenario" listed above and require the user to pass in an `ExtensionConfig` instance to the `Extension` constructor.  This isn't terrible, but adds some complexity.