Skip to content

Inferring type from a generic constraintΒ #54673

Closed as not planned
Closed as not planned

Description

@thany

Suggestion

πŸ” Search Terms

infer, generic, constraint

βœ… 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

It doesn't seem possible yet, to use an inferred type from a generics constraint. An example will show what I mean:

πŸ“ƒ Motivating Example

I feel like I should be able to write something like this:

function foo<T extends Array<infer U>>(array: T): Array<NonNullable<U>> {
  // ...
};

So this would infer the U out of the Array type constraint, giving me effectively the type of items in that array. I could then use that type to construct another type based on it.

πŸ’» Use Cases

This particular example can be rewritten to not require this feature request:

function foo<T>(array: Array<T>): Array<NonNullable<T>> {
  // ...
};

But this has two disadvantages:

  • The array type is lost, and an assumption has to be made about its actual type.
  • Calling this function with an explicit generic argument, has to occur with the inner type, which may be tricky to get hold of.

Advantages of having this feature would not be limited to arrays. It would mean that given a certain constraint, is becomes possible to use the generic types that are enclosed in that type. So, another potential use-case would be:

function foo<T extends { x: infer A, y: infer B}>(record: T): [A, B] {
  // ...
};

Here, rewriting it to match the current way typescript works:

function foo<A, B>(record: { x: A, y: B }): [A, B] {
  // ...
};

Apart from more repetition and (as said before) losing the generic type parameter of record, it's all about how to call this function. I can no longer just plonk the record type into this function, but am now required to put in whatever is contained within it. I may not have that information. This is of course only in case I need to explicitly pass the generics parameters.

Activity

  1. fatcerberus commented on Jun 16, 2023

    @fatcerberus

    I'm pretty sure this is a duplicate, but I can't find the other issue(s) at the moment.

    This is interesting. I was initially thinking you could already do this by adding an additional type parameter, but it turns out that doesn't work either:

    function foo<U, T extends Array<U>>(array: T): Array<NonNullable<U>> {
      // ...
    };
    
    const food: string[] = [ "foo", "bar" ];
    foo(food);  // infers U = unknown :(

    Which makes sense now that I think about it because constraints aren't considered inference sites (which incidentally might make this proposal DOA).

  2. fatcerberus commented on Jun 16, 2023

    @fatcerberus

    After further searching, I think this is a duplicate of, or at least strongly related to, #52791.

  3. thany commented on Jun 16, 2023

    @thany
    Author

    Ahh, the guy used the other jargon - conditional vs constraint πŸ™‚

    (it is called a constraint, right?)

  4. fatcerberus commented on Jun 16, 2023

    @fatcerberus

    Constraint: T extends U - U is the constraint. infer is not (currently) allowed here.

    Conditional: T extends U ? Foo : Bar - conditional type, U is the "check type", where infer is currently allowed and is scoped to the true branch of the ternary.

  5. typescript-bot commented on Jun 19, 2023

    @typescript-bot
    Contributor

    This issue has been marked as 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

  6. locked as resolved and limited conversation to collaborators on Oct 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DuplicateAn existing issue was already created

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions