You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Assign defaults to generic types in lib.d.ts #24834
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:
interfaceArray<T>{
...
}
To:
interfaceArray<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:
typeArrayKeys=keyofArray;
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)
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?
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>.
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?
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?
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.
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.
Activity
DanielRosenwasser commentedon Jun 9, 2018
I'm not so sure
Arraybuys you a lot overany[]- but I could certainly see savings inMaporSet. 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?mhegazy commentedon Jun 11, 2018
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 useArray<any>.andrewlowndes commentedon Jun 12, 2018
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?
mhegazy commentedon Jun 12, 2018
These types are not inferred. these types that are explicitly specified. so why would some one take the time to write
Arrayfor type safety vs than the implicitany, 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?
mhegazy commentedon Jun 12, 2018
on the flip side, if this is allowed, users will feel compelled to have a lint rule that says you can not specify
Arraywithout 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.
jcready commentedon Jun 12, 2018
Is the pope catholic?
RyanCavanaugh commentedon Jun 25, 2021
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.