Repository: TypeScript
Issue: Constructor generic types and `this` parameter (TS1092, TS2681)
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨
 
Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.
 
Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ
 
-->
 
## Search Terms
 
constructor
this
parameter
type
 
## Suggestion
 
Allow constructors to specify a `this` parameter, and allow generic type parameters on constructors.
 
- Remove TS1092: Type parameters cannot appear on a constructor declaration.
- Remove TS2681: A constructor cannot have a 'this' parameter.
 
## Use Cases
### Subclass Type Inference
The primary reason for this change would be to allow constructors to take in parameters that are in some way related to the `this` type of a _subclass_. Specifically, it provides a solution for the commonly requested pattern of initializing classes with all of their required properties:
 
```typescript
class Base {
    foo!: boolean;
    constructor<T extends Base>(this: T, data: T) { // or data: Partial<T>, etc
        Object.assign(this, data);
    }
}
class A extends Base {
    bar: number = 0;
}
class B extends Base {
    baz: string = 'hello';
}
new A({foo: true, bar: 123});
new B({foo: false, baz: 'world'});
```
 
The huge advantage of this pattern is that the constructor does not have to be individually specified for every single subclass to maintain type safe initialization. In use cases where a class has many subclasses (e.g. various message types of a protocol that all share some common properties in the base class), the choice is between having manually typed constructors for each subclass and accepting the `any` type to be used with `Object.assign`, which opens up various potential problems.

Most other use cases are directly relevant in this example.

### Single-Use Generics
Class methods use generics locally for situations where the inputs and outputs of the method are independent of the class itself. 

While this might be less common with constructors, there are situations where generics are only necessary during initialization and become redundant afterwards. In these situations the types are not inherently tied to the overall class, so they should ideally be defined separately.

```typescript
class Foo {
    constructor(foo: Foo, options: FooOptions);
    constructor<T extends Bar>(bar: T, options: BarOptions<T>); // make sure BarOptions are specific to T!*
    constructor(fooOrBar: Foo | Bar, options: FooOptions | BarOptions<any>) { // don't care at runtime anyway
        if (fooOrBar instanceof Foo) {
            this.applyFooOptions(options);
        } else {
            this.applyBarOptions(options);
        }
    }
```

When referenced elsewhere in the codebase the class can then be free of generics clutter which was only necessary during initialization.

### Reach-Through Self-Referencing Generics
Self-referencing generics (not sure this is the correct name) can be useful for obtaining information about a subclass, but they are only applicable if there is one layer of subclassing:

```typescript
class Base<T extends Base<any>> {
    constructor(data: T) {
        Object.assign(this, data);
    }
}

class Foo extends Base<Foo> {}
new Foo({});

class Bar extends Base<Bar> {
    barInfo: string;
}
new Bar({barInfo: "test"});

// Bar is a standalone class so it must set the generic, but it also has a subclass that adds some extra info
class BarAndMore extends Bar { // bar has no generics, can't change Base<Bar> constructor parameter ?
    barExtendedInfo: string;
}
new BarAndMore({
    barInfo: "test",
    barExtendedInfo: "more" // ERROR: Object literal may only specify known properties, and 'barExtendedInfo' does not exist in type 'Bar'.
});
```

With constructor generics the following would become possible, even without `this` parameters:

```typescript
new BarAndMore<BarAndMore>({...barAndMore});
```

And when the `this` parameter _is_ used, it becomes a way to reach directly to the furthest subclass, which self-referencing generics prevent. This is of course already available in ordinary methods.

### Decorators 

```typescript
class Base {
    constructor<T>(this: {id: T}, id: T) { this.id = id; }
}
class A {
    @IsNumber() id: number;
}
class B {
    @IsString() id: string;
}
new A(123);
new B(123); // ERROR: Argument of type 'number' is not assignable to parameter of type 'string'.
```

## Examples
 
```typescript
export type TypeKeys<T, U> = {
    [P in keyof T]: U extends T[P] ? P : never;
}[keyof T];
export type FunctionKeys<T> = TypeKeys<T, (...args: any[]) => any>;

class Base {
    def = true;

    foo!: boolean;
    constructor<T extends Base>(this: T, data: Omit<T, 'def' | FunctionKeys<T>>) {
        Object.assign(this, data);
    }

    test() {}
}
class A extends Base {
    bar: number = 0;
}
class B extends Base {
    baz: string = 'hello';
}
new A({foo: true, bar: 123});
new B({foo: false, baz: 'world'});
```

## Problems
Allowing constructors to have generic types does effectively create two sets of generics, which is an issue as mentioned here https://github.com/microsoft/TypeScript/issues/10860#issuecomment-246456721, but a number of solutions exist to this problem:

```typescript
class Foo<T> {
  constructor<U>(x: T, y: U) { }
}

new Foo<number, string>(0, '') // A: concatenate generics
new Foo<number><string>(0, '') // B: separate type arguments
new (Foo<number>)<string>(0, "") // C: wrapped generic class

// https://github.com/microsoft/TypeScript/issues/10860#issuecomment-300918682
class Bar<T> {
  constructor<U = string>(x: T, y: U) { }
}
new Bar<number>(0, '') // D: only allow constructor generics if a default is provided
```

## Alternatives
The initialization pattern is also currently achievable using a static method.

```typescript
class Base {
    foo = false;

    // To prevent user from initializing directly request impossible parameters, since protected does not work
    constructor(internalGuard: never) {}

    static construct<T extends Base>(
            this: new (internalGuard: never) => T,
            params: T) :T {
        return Object.assign(new this(<never>undefined), params);
    }
}
class A extends Base {
    bar!: number;
}
A.construct({foo: true, bar: 1});
```
 
## 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.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).