Skip to content

Assign defaults to generic types in lib.d.ts #24834

Closed

Description

Search Terms

array, generic, default

Suggestion

Assign a default generic type to built-in types that require generics. More specifically the Array type.

Modify lib.d.ts and change existing definitions that use generics from:

interface Array<T> {
...
}

To:

interface Array<T = any> {
...
}

Use Cases

Will allow people more flexibility with how much type information they want to provide in their project and to more easily and loosely match high level types without validating child types.

Examples

Can then do the following without needing to care about the generic type:

type ArrayKeys = keyof Array;

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. new expression-level syntax)

Activity

  1. DanielRosenwasser commented on Jun 9, 2018

    @DanielRosenwasser
    Member

    I'm not so sure Array buys you a lot over any[] - but I could certainly see savings in Map or Set. I feel like this comes up during migration, but the problem is that once you're really authoring in TypeScript, I don't think you ever want this sort of behavior if you leave off the type arguments. So how does a user avoid this when they forget type arguments?

  2. mhegazy commented on Jun 11, 2018

    @mhegazy
    Contributor

    We have discussed this in the past, and felt that if you, in a type position, take the type to write Array, you might as well tell us what type it is, or just use Array<any>.

  3. andrewlowndes commented on Jun 12, 2018

    @andrewlowndes
    Author

    I wanted to make this suggestion to set the convention for always defaulting generic types where a default can be defined. Is the general feel that strict typing should always be preferred?

  4. mhegazy commented on Jun 12, 2018

    @mhegazy
    Contributor

    These types are not inferred. these types that are explicitly specified. so why would some one take the time to write Array for type safety vs than the implicit any, but yet they do not want to write what is the element type..
    My question here is what is the scenario this would be solving?

  5. mhegazy commented on Jun 12, 2018

    @mhegazy
    Contributor

    on the flip side, if this is allowed, users will feel compelled to have a lint rule that says you can not specify Array without a type..
    I believe having these options that make users needing to choose a way among multiple equivalents (similar to semicolon or no semicolon, const vs let, etc..) is a language designer mistake.

  6. jcready commented on Jun 12, 2018

    @jcready

    Is the general feel that strict typing should always be preferred?

    Is the pope catholic?

  7. added
    DeclinedThe issue was declined as something which matches the TypeScript vision
    and removed on Jun 25, 2021
  8. RyanCavanaugh commented on Jun 25, 2021

    @RyanCavanaugh
    Member

    There doesn't seem to be much user demand for this, and we'd certainly upset a lot of people who didn't like infectious anys creeping in. Splitting the lib by option is very problematic so I don't think we'll be taking this up.

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

    DeclinedThe issue was declined as something which matches the TypeScript visionSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions