generics in constructor

[y-nk]

🔍 Search Terms

• "generics in constructor"
• "generics"
• "constructor"
• "private class generics"
• "private generics"

✅ 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I'd like to know if we can add the capability to have generics in constructors ; after all they are functions like any other, and some parameters of constructor could require generics to extend a type for any reason.

type Foo = {
  foo: string
}

class Bar {
  constructor<T extends Foo>(foo: T) {
    // do something with foo: T shape
  }
}

📃 Motivating Example

My real-life use-case is to implement a base repository class, which would need a property typed when calling super() for which i need to keep type integrity, therefore i'd need to be able to use extends in constructor:

// ↓ types to understand why need type integrity (→ iterate on keys)
type SimpleProjection<T> = {
  [K in keyof T]?: boolean
}

type FilterKeysWhenEquals<T extends object, V> = keyof {
  [K in keyof T as T[K] extends V ? K : never]: T[K]
}

type FilterKeysWhenDiffers<T extends object, V> = keyof {
  [K in keyof T as T[K] extends V ? never : K]: T[K]
}

type HasFalse<T extends object> = T[keyof T] extends false ? true : false

type Projected<
  Schema extends object,
  Projection extends object | undefined,
  DefaultProjection extends object | undefined,
> = Projection extends undefined
  ? Schema
  : HasFalse<Projection & {}> extends true
    ? // Exclusion mode
      Omit<Schema, FilterKeysWhenEquals<(Projection & {}) | (DefaultProjection & {}), false>>
    : // Inclusion mode
      Pick<Schema, FilterKeysWhenDiffers<Projection & {}, false>>

// ↓ said class
export class Repository<
  Schema extends object,
  DefaultProjection extends ExclusionProjection<Schema> | undefined = undefined,
> {
  constructor(
    protected model: Model<Schema>,
    protected projection?: DefaultProjection,
  ) {}

  async findById<Projection extends SimpleProjection<Schema> | undefined = undefined>(
    id: ID,
    projection?: Projection,
  ) {
    return this.model
      .findById(id, this.mergeProjection(projection))
      .lean<Projected<Schema, Projection, DefaultProjection>>({ transform })
  }
}

// ↓ current usage
const EXCLUDE_DEFAULTS = { passkeys: false, password: false, salt: false } as const

export class UserRepository extends Repository<User, typeof EXCLUDE_DEFAULTS> {
  constructor() {
    super(new UserModel(), EXCLUDE_DEFAULTS)
  }
}

but if i could have generics in constructor, i would be able to write:

// ↓ one generic at class level, the 2nd one in constructor
export class Repository<Schema extends object> {
  constructor<
    DefaultProjection extends ExclusionProjection<Schema> | undefined = undefined,
  >(
    protected model: Model<Schema>,
    protected projection?: DefaultProjection,
  ) {}

  async findById<Projection extends SimpleProjection<Schema> | undefined = undefined>(
    id: ID,
    projection?: Projection,
  ) {
    return this.model
      .findById(id, this.mergeProjection(projection))
      .lean<Projected<Schema, Projection, typeof this.projection>>({ transform })
  }
}

// ↓ can inline the object directly, no need to create a const just so that i can pass `typeof theConst` in 2nd generics
export class UserRepository extends Repository<User> {
  constructor() {
    super(new UserModel(), { passkeys: false, password: false, salt: false })
  }
}

💻 Use Cases

1. What do you want to use this for? Have simpler syntax when writing constructors

2. What shortcomings exist with current approaches? Need to complicate class generics and merge them with constructor generics (which could be 2 different scopes sometimes)

3. What workarounds are you using in the meantime? manual mode. verbose and need specific structure, but acceptable enough at least for my use-case.

[jcalz]

Note: not a TS team member, feel free to ignore me.

I was going to say this is a duplicate of #40451, but looking at the motivating use case I'm not sure this is a coherent request.

For a class of the form class Foo { constructor <T>(public t: T) {} }, what is the type of const x = new Foo(0) and how does it differ from the type of const y = new Foo("")? If they are both just Foo then information about T is completely lost, and x.t and y.t are both of type unknown or something. Parameter properties are just shorthand for declaring and initializing a field. What's the type of the field t? It's T? But that type is supposed to be scoped just to the constructor, not to the class? It's like you want there both to be and not to be a class generic type parameter here.

Maybe this is really a duplicate of #36456. You actually do want the class to have a generic type parameter, you'd just like the type argument to be inferred from super() calls in subclass constructors.

[RyanCavanaugh]

I can see a use case of some kind that's roughly like

class Foo<T> {
  constructor<U>(arr: U[], item: U, somethingElse: T) {
    // idk
  }
}

This is supported by some OOP languages but not others, so it's neither incoherent nor obviously mandatory

[jcalz]

@RyanCavanaugh Sure, but that's not the motivating use case. Your example looks like #40451 (which would imply this is a duplicate). But the motivating use case is writing something like

class Foo<T> { 
  unmentionableField: U;
  constructor<U>(unmentionableField: U, somethingElse: T) {
    this.unmentionableField = unmentionableField; 
  }
}

but using a parameter property so that it only looks like U doesn't try to escape the constructor. Incoherent or not, that wouldn't be possible even if the feature you're talking about were implemented.

[RyanCavanaugh]

Gotta admit I did not pay too much attention to the long type variable names in the extended example. Yeah, it is not permissible to have a type parameter do a lexical escape like that, even indirectly. #40451 as phrased is much hairier because it tries to simultaneously bring in this, which is confusing to reason about.