3 ms·
The logic here seems inconsistent. Of course the keys could be different at runtime, but that can happen in all sorts of situations. I could type an API respons
by ralusek 3y ago
The logic here seems inconsistent. Of course the keys could be different at runtime, but that can happen in all sorts of situations. I could type an API response and the API could change, or I could've been wrong about the response type, but it's not like Typescript says "well we refuse to accept your API typing because it could be wrong at runtime." I feel like it just makes more sense to trust that the object type is what we've said it is, and if it's not, THAT is the problem, and not that TypeScript let us believe that the keys were type keyof T.
- matt_kantor 3y agoIn all of your examples you're either starting from `any` or doing a type assertion somewhere along the line. That's explicitly opting-out of type checking, the same way that asserting an `Object.keys` return value is `(keyof T)[]` would be. > I feel like it just makes more sense to trust that the object type is what we've said it is The object type is what we've said it is. The type is correct, it just doesn't necessarily specify every last detail of your value, because subtyping is a thing. For example: class Pet { name: string } class Dog extends Pet { isAGoodBoy: boolean } const f = (pet: Pet): keyof Pet => Object.keys(pet) // this call should be allowed, but that means `f`'s return type is wrong f(new Dog())
- madeofpalk 3y agoDevs on the Typescript team have commented that ideally they would rather JSON.parse() returns unknown, but it wasn't around when lib.d.ts was first made, and it would be too big of a breaking change to do so now.