Add stricter parameter types for Object.values and Object.entries

[ghost]

Fixes #20550

Added | string | number | boolean | symbol to avoid falling into the second overload unnecessarily; Object.values on a primitive returns [] of these so it's effectively a never[] in that case (though we infer {}[]).
I'm also not too happy about returning any from builtin functions. --noImplicitAny won't help you there. The only case I found where the first overload won't match any more is Object.values(() => {}), in which case a return of {}[] is probably better since a function's unlikely to have the properties you intend to get.

[weswigham]

@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.

[Jessidhia]

@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.

[ghost]

@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.

[weswigham]

@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]

do not use keyof here. same reasoning as #13989 (comment)

[mhegazy]

same here

[ghost]

@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?

[mhegazy]

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.

[ghost]

Waiting for #21075, then will merge from master

[aboyton]

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