GeezerVison

Hi Ethan Resnick (@ethanresnick), I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

Mohamed Hegazy (@mhegazy) I've updated this PR to replace keyof T & string with simply keyof T, as the string intersections are no longer necessary now that keyof always returns a string (from #12425). So this should be good to go.

Cc Anders Hejlsberg (@ahejlsberg): you expressed skepticism about typing Object.keys with keyof in #12289 (comment). But if/now that for in is typed with keyof (#12314), it seems like this makes sense, no?

Ethan Resnick (@ethanresnick) My reservations about Object.keys returning (keyof T)[] still hold. It makes sense only in the domain of type variables (i.e. T and keyof T). Once you move to the instantiated type world it degenerates because an object can (and often does) have more properties at run-time than are statically known at compile time. For example, imagine a type Base with just a few properties and a family of types derived from that. Calling Object.keys with a Base would return a (keyof Base)[] which is almost certainly wrong because an actual instance would be a derived object with more keys. It completely degenerates for type {} which could be any object but would return never[] for its keys.

BTW, I have the same reservations about Object.entries which I notice is now typed this way.

Note that the changes we made to for-in specifically apply only when objects have a type parameter type. In for (let x in obj) ... where obj is of type T, if T is a type parameter we infer keyof T for x, but otherwise we infer type string. To do the same for Object.keys would require some way to constrain a type argument to only be type parameter, which currently isn't possible.

Anders Hejlsberg (@ahejlsberg) What you're saying makes sense, assuming I'm understanding it correctly, makes sense. I'll close this PR then. Feel free to revert #12207 as well.

Anders Hejlsberg (@ahejlsberg) And what about using it on Readonly<T> type?

When an object has an index though, shouldn't it return the index type?

const a: {[key: number]: any} = {};
Object.keys(a) // should be a number

Basically with an index, we are saying that the index HAS to be a certain type, so the above concern about dynamic keys doesn't follow.

...unless javascript casts to strings in Object.keys...

Dylan Stewart (@dyst5422) Keys are returner as strings.
As well in for..in you get strings.

var a={1:2};
alert(typeof Object.keys(a)[0])

Anders Hejlsberg (@ahejlsberg) I'm not sure I understand your reasoning. If you're object has type {[key: string]: number} then Object.keys will return string[]. But if you object is a literal type {a: 1, b: 2} then the return type will be Array<"a" | "b">. That makes sense doesnt it?

Chet Corcos (@ccorcos) no, because lots of objects with other extraneous keys can have type { a: 1; b: 2 }. For example,

declare const x: { a: 1, b: 2, c: 3 }
const y: { a: 1; b: 2 } = x

for (const k in Object.keys(y)) {
  // what should be the type of k?
}

k: 'a' | 'b' is wrong, because k will take on the value 'c' as well!

I see. Sounds like that should be a type error then. haha

I understand the reasoning here and it makes sense, but --strict just made this a lot more annoying because now with strictFunctionTypes you can no longer do this:

interface Foo { foo: string; }
declare const foo: Foo

Object.keys(foo).forEach((key: keyof Foo) => { }) // Error

Error: Argument of type '(key: "foo") => void' is not assignable to parameter of type '(value: string, index: number, array: string[]) => void'.

Which is a pain because with noImplicitAny you can't use string as a lookup:

Object.keys(foo).forEach(key => {
  foo[key] // Error: Element implicitly has an 'any' type because type 'Foo' has no index signature.
})

You have to assert key as keyof T to use it as a lookup.

That's pretty annoying. Is there no way we could allow key to be keyof T? (For cases you're sure T only actually has keys of T)? Since AFAIK there's no way to actually check at runtime that key is in keyof T there seems to be no safe way to ensure that's true, so an assertion seems necessary (without bringing in a runtime type system of some kind).

Yeah, the only other workaround also ends up being kind of gross to write. You can write it, but it's gross:

(Object.keys(foo) as (keyof Foo)[]).forEach((key) => { ... })

I just found my way here after writing up an issue around that b/c of the really poor ergonomics associated with it. Perhaps this could work if the exact types proposal landed? 🤔

I'm not sure why this is worth debating here. It's really easy to write your own function which does this "at your own risk" if you want it:

export function keys<O>(o: O) {
  return Object.keys(o) as (keyof O)[];
}

FWIW, my comment wasn't offered as "debate." I was mostly thinking out loud if there were ways to get both what many users will expect and satisfy the point made up-thread last year. 🙂

I believe the updated version for 2.9 is

export const keys = Object.keys as <T>(o: T) => (Extract<keyof T, string>)[];