Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable Generics to be inferred on assignment #47755

Open
TrevTheDev opened this issue Feb 7, 2022 · 0 comments
Open

Enable Generics to be inferred on assignment #47755

TrevTheDev opened this issue Feb 7, 2022 · 0 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@TrevTheDev
Copy link

TrevTheDev commented Feb 7, 2022

Suggestion

This suggestion is to enable Generics to be inferred and defined in a single step. This could look something like this:

const x: InferredGeneric<*> = [....] as const 
// returning const x = [...] as const; x: InferredGeneric<typeof x>

The <*> indicates that the default type of the [...] as const should be passed as the first argument to InferredGeneric and InferredGeneric's return type used as the final type for x.

Even better would be to combine this with issue: #30680:

// probably an even better solution would be to enable it to be used with `as const`:
const x: InferredGeneric<* as const> = [...]

🔍 Search Terms

"infer generic type"

✅ Viability Checklist

My suggestion meets these guidelines:

  • [ ✅] 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 TypeScript's Design Goals.

⭐ Suggestion

Enhance generics to accept <*> or <* as const> when they are used and this would mean the default type of the variable being defined is passed to the generic and whatever it returns would be the final variable type.

📃 Motivating Example

If generics cannot be defined and inferred in a single step, then it breaks the DRY principle as one would have to do the following:

type GenericFn<T extends unknown[]> = (...args: T) => number | string
type InferGenericFn<T extends ((...args: any) => number | string)> = T extends (...args: infer A) => number | string ? GenericFn<A> : never
type InferGenericFnArray<T extends readonly unknown[]> = T extends readonly [...genericFns: infer P] ? { [I in keyof P]: P[I] extends  ((...args: any) => number | string) ?  InferGenericFn<P[I]> : never} : never

const fnArray = [
  (value: number) => value,
  (text: string) => parseInt(text, 10),
] as const

// STEP 1: infer generic
type InferredGenericFnArray = InferGenericFnArray<typeof fnArray>

// STEP 2: apply inferred generic to array for type checking
const fnArrayNotDRY: InferredGenericFnArray  = [
  (value: number) => `${value}`,
  (text: string) => true,
]

This solution would combine STEP 1 and STEP 2 into a single easy to read and understand step, and so would become:

type GenericFn<T extends unknown[]> = (...args: T) => number | string
type InferGenericFn<T extends ((...args: any) => number | string)> = T extends (...args: infer A) => number | string ? GenericFn<A> : never
type InferGenericFnArray<T extends readonly unknown[]> = T extends readonly [...genericFns: infer P] ? { [I in keyof P]: P[I] extends  ((...args: any) => number | string) ?  InferGenericFn<P[I]> : never} : never

// STEP 1&2: combined in a single step
const fnArray: InferredGenericFnArray<* as const> = [
  (value: number) => value,
  (text: string) => parseInt(text, 10),
]

code

💻 Use Cases

Makes generics more powerful by inferred them and applied the resultant definition in a single step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

2 participants