-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Change Map default generic parameters from "any" to "unknown" #52552
Comments
Two type definitions for two different types being different is not a per se bug. They have different use cases, etc.. Please make a positive case for one or the other to change. |
Sets are used in the specific subset of situations where you need a We can visualize the two types like this: Based on this, we can establish a type equality of: Because of this "equality", we would expect
Thus, because of this transitivity, we would expect that the default parameter of By breaking this transitivity in an arbitrary(?) way, TypeScript is introducing a subtle pitfall that interferes with end-users ability to properly reason about their code. As a short example, imagine that a lint rule exists that forbids the const myMap1 = new Map(); // Fails the lint rule.
const myMap2 = new Map<string, true>(); // Passes the lint rule. But such a rule would not work properly with sets: const mySet1 = new Set(); // Passes the lint rule. WTF?
const mySet2 = new Set<string>(); // Passes the lint rule. Of course, other pitfalls exist as well. The main difference between |
I see two courses of action:
Either of these changes would restore the parity and alleviate the issues discussed in my previous comment. In my mind, option 1 (changing |
Retsam from Discord argues that parity between For example, consider the following code: interface Person {
id: string;
name: string;
}
class PersonStore {
private people = new Map();
storePerson(person: Person) {
this.people.set(person.id, person)
}
getName(personId: string): string {
// Oops, this should have been name, not username
return this.people.get(personId)?.username ?? "???";
}
} If TypeScript changed the default of So, if you don't really care about |
Right, what I'm saying is literally log that suggestion. Two definitions being different isn't an actionable bug; "Change the type signature of |
const cache = new Map();
const item: string = cache.get('foo'); |
This issue has been marked as 'Not a Defect' and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
Suggestion
Description
Here, the behavior of the types is inconsistent. Naively, I would expect both of them to be
unknown
, or both of them to beany
, depending on what Microsoft wants to do. (Would it result in safer code for both of them to default tounknown
?)More Info
I asked about this inconsistency in the TypeScript discord:
🕗 Version & Regression Information
I tested on the playground, and:
any
.unknown
, causing the inconsistency.The text was updated successfully, but these errors were encountered: