Add an overload to `Object.fromEntries` when called with const tuples

lib Update Request

Object.fromEntries as is declared today results in a loss of key names and a unionization of all values, or a complete loss of information and type of any. This change would make it so that it is possible to create strict objects — from const tuples only.

Note that the usage of fromEntries with Arrays and non-readonly tuples cannot be made sound, so this issue only discusses the narrow case of const tuples.

Sample Code

const obj1 = Object.fromEntries([
  ['1', 2],
  ['3', 4],
] as const)
// this should result in an object of type: {1: 2, 3: 4}, but results instead in: { [k: string]: 2 | 4 }

const obj2 = Object.fromEntries([
  ['1', 2],
  ['3', '4'],
] as const)

// should result in an object of type: {1: 2, 3: '4'}, but results in: any

The how & example

This could be achieved by adding a new overload to Object.fromEntries in the case it is called with const tuples only. This distinction is vital, because not distinguishing between Arrays, tuples and const tuples would make this change unsound. Only properties of a readonly tuple are guaranteed to be there at runtime, since they cannot be reassigned.

Here’s a working proof-of-concept playground that should be sound in all cases, including the edge case of using a union type for the key.

The type is somewhat complex right now, so it would be great if we could somehow simplify it. Suggestions are welcome.

Related issues were previously closed, because the change would have been unsound without guarding for const tuples only (https://github.com/microsoft/TypeScript/issues/35745, https://github.com/microsoft/TypeScript/issues/49305, https://github.com/microsoft/TypeScript/issues/43332). Here however, the discussion is around const tuples only.

Configuration Check

My compilation target is es2022 and my lib is es2022.

Missing / Incorrect Definition

• Object.fromEntries

Note

Opened by request of @sandersn in #50203.

[webstrand]

I really would rather avoid a conditional return type, at least not as the last overload. By supporting a reduced, but still improved, set of features I think this is better:

// Most generally useful
declare function fromEntries<T extends readonly [PropertyKey, unknown]>(
  entries: Iterable<T>
): { [P in T as P[0]]?: P[1] }

// Support wonky union types like `[["foo", 1]] | Iterable<["bar", 2]>`
declare function fromEntries<K extends PropertyKey, V>(
  entries: Iterable<readonly [K, V]>
): { [_ in K]?: V }

// For people destructuring `fromEntries`
declare function fromEntries(entries: Iterable<readonly [PropertyKey, unknown]>): { [key: PropertyKey]: unknown }

I just noticed that this breaks the obj2_fromMixed case

[webstrand]

Another failing test case

const x = fromEntries([] as [["foo", 1]] | Iterable<["bar", 2]>);