Empty type inferred by Object.entries

[salehe]

TypeScript Version: 2.7.1

Search Terms: Object entries empty TS2365

Code

let o: any = {x: 5};

let p = Object.entries(o).map(([k, v]) => v + 1);

Compile command: tsc --lib es2017,es2017.object a.ts

Expected behavior:
This should compile without any error, assuming v: any.
This was the case for Typescript 2.6.2 at least.

Actual behavior:
(3,43): error TS2365: Operator '+' cannot be applied to types '{}' and '1'.

Following codes compile without errors:

let o: object = {x: 5};

let p = Object.entries(o).map(([k, v]) => v + 1);

let o: any = {x: 5};

let p = Object.entries(o).map(([k, v]: [any, any]) => v + 1);

Looks like this is due to #20553. Previously the second overload of entries took any, now it takes {}. Previously we would match the second overload while now we match the first.

declare function values<T>(x: { [key: string]: T }): T[];
declare function values(x: any): any;

declare function values2<T>(x: { [key: string]: T }): T[];
declare function values2(x: {}): any;

values(a)[0].toUpperCase(); // No error
values2(a)[0].toUpperCase(); // Error

This behavior seems sort of strange so I'm wondering if it's intended.

Talked with @sandersn and it looks like the problem would be fixed if we considered any to have an implicit index signature [key: string]: any in getImplicitIndexTypeOfType. (But we also have to make sure control flow gets there if the source type is any, so not quite as simple as that).

Currently the problem is that when choosing an overload we use a subtype relationship. any subtypes any but does not subtype {}, so after the change we end up choosing the first overload instead of the second.

[rhys-vdw]

Just jumping in here... I also get a problem with this code:

  const x: Readonly<{ [id: number]: number }>  = { 5: 1 }
  const entries = Object.entries(x)

It must be Readonly and have a numeric key.

entries is incorrectly typed as const entries: [string, {}][]

@rhys-vdw That looks like #22105 -- No problem with id: string.

[mhegazy]

I wounder if we should just get back to any. seems like our attempts to make it better have caused more trouble.

[salehe]

Actually my case was fixed in 2.8-rc but again happening in 2.8.1 .

[EliSnow]

Can this issue be expanded so Object.keys(o) and Object.entries(o) return type for the keys is keyof typeof o, rather than just string?

[RyanCavanaugh]

@EliSnow no, see #12253