@Andy-MS We could just define values as values<T>(o: T): T[keyof T][]; (and similarly for entries). These definitions are pre-index types AFAIK, and we can just do better now, I think.

@weswigham the problem there is the unsoundness because of structural non-sealed types

const a = { a: 'a string', b: 123 }
const b: Pick<typeof a, 'a'> = a
const values = Object.values(b) // string[]; but actually has a number inside too

EDIT: my example actually turns out to already be incorrect today, because of the overload that tries to handle dictionary types.

@weswigham What would you think of that signature with T extends object? The function will technically work at runtime if you pass in a string, it's not really useful unless you're passing in an object.

@Kovensky any time you alias a type you lose information w.r.t. the index operator. But the thing is, I'm pretty sure that definition (at least for T extends object, like @Andy-MS suggests), is more practically useful, since you'll get the types for all the fields we do know about (instead of the unsafe any). Honestly, your complaint is just a function of how the keyof type operator works; but the more tightly your types match your behavior, the more accurate it is. You use it on any type you've aliased (thus discarded information) and you'll get results for the alias, not the original type.

@mhegazy @weswigham The original goal was to not accept undefined and null here. How about making this PR just change values(o: any): any[]; to values(o: {}): any[] (and the same for entries) and leaving the rest for later?

The original goal was to not accept undefined and null here. How about making this PR just change values(o: any): any[]; to values(o: {}): any[] (and the same for entries) and leaving the rest for later?

that would work.

Waiting for #21075, then will merge from master

Thanks. Really loving the TypeScript project and how quickly and thoroughly you fix any reported bugs.