Repository: TypeScript
Issue: [Feature Request] Abstract Interfaces with Undeclared Properties
Labels: Suggestion,Awaiting More Feedback

Edit: changed `partial` to `abstract` because I think it makes more sense.

## Search Terms

Abstract Mapped Types
Partial Types
Meta Types
Super Types

## Suggestion

I'd like to propose an expansion to the TS syntax that allows you to create `abstract` interfaces with `undeclared` properties which force child types to declare those properties with any value, no matter what their value type may be in the child type. This can be helpful for identifying code which maps two objects to one another, where a developer wishes for TypeScript to warn of properties that are missing between two types. Optional properties should be allowed in the concrete type, but I don't think optionality should be defined by the abstract interface.

Both `abstract` and `undeclared` are just first-draft words, and I think `abstract` makes sense because it is the interface equivalent of `abstract class`.

## Use Cases

Where object mapping is used. For example, translating query string parameters to form values. The query string will always return parameters as a string or string array in the case where there are multiple parameters.

`example.com/?name=john%20doe&age=21`

```
abstract interface IFormQueryStringMap {
    name: undeclared;
    age: undeclared;
}

interface IFormQueryString extends IFormQueryStringMap {
    name?: string;
    age?: string;
}

interface IFormValues extends IFormQueryStringMap {
    name: string;
    age: number;
}

const selectFormValuesFromQueryString = (queryString: IFormQueryString): IFormValues => ({
    name: queryString.name || '',
    age: Number(queryString.age),
});
```

On loading the page, the app will translate unserialize `location.search -> IFormQueryString -> IFormValues` and populate the form. On submitting the form it will translate from `IFormValues -> IFormQueryString` and serialize to `location.search`. I use patterns like this often, and they can be subject to significant manual review. I think TypeScript is in unique position to solve a mapping problem like this. It will not catch the case where a developer forgets to map `IFormValues['age']` to `IFormQueryString['age']`, though.

## Examples

```
abstract interface AbstractInterface {
    prop1: undeclared;
    prop2: undeclared;
    prop3: undeclared;
    prop4: string; // acts normally
    prop5?: string; // acts normally
    propError?: undeclared; // error: cannot assign optionality to undeclared properties because it would declare undefined
}

abstract interface AnotherAbstractInterface extends AbstractInterface; // OK

interface ConcreteInterface extends AbstractInterface {
    // error: prop1 is undeclared
    prop2: string;
    prop3?: string;
}

type ConcreteType = AbstractInterface; // error prop1 is undeclared
type ConcreteType = AbstractInterface & {
    prop1: string; 
    prop2: number;
    prop3: object;
} // OK

type Prop1 = AbstractInterface['prop1']; // error: AbstractInterface['prop1'] is undeclared
type Prop2 = ConcreteInterface['prop2']; // string
type Prop3 = ConcreteInterface['prop3']; // string | undefined
type Prop4 = ConcreteInterface['prop4']; // string
type Prop5 = ConcreteInterface['prop5']; // string | undefined
```

## Can this be done today?

Yes, but it would write JavaScript output.

```
interface IFormQueryString {
    prop1: string;
    prop2: string;
    prop3?: string;
    prop4: string;
    prop5?: string;
}

type FormQueryMap = Record<keyof IFormQueryString, any>;
const formQuery = {
    // Error on next assignment, prop1 is undefined
    prop2: '';
    prop3: '' as string | undefined;
    prop4: '';
    prop5: '' as string | undefined;

// this assignment makes sure that formQuery has all keys of IFormQueryString
const formQueryMap: FormQueryMap = formQuery;

export type FormQuery = typeof FormQuery;
```

## Checklist

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, etc.)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

For this last one, I'm not certain. I think it adds type safety, but it also might be too "meta". It might also be a case for decorators or annotations or something else.