Add stricter Object.fromEntries for constructing from const tuples

[niieani]

Related issue: #50379.

UPDATE: The version in this branch is unsound, but see the last comment here with a proposed solution that is sound.

---

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 makes it so that it is possible to create strict objects from const tuples.

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

// now results in an object of type: {1: 2, 3: 4}, previously { [k: string]: 2 | 4 }

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

// now results in an object of type: {1: 2, 3: '4'}, previously any

Fixes #35745, #49305, #43332

[typescript-bot]

It looks like you've sent a pull request to update our 'lib' files. These files aren't meant to be edited by hand, as they consist of last-known good states of the compiler and are generated from 'src/lib' or possibly our lib generator. Unless this is necessary, consider closing the pull request and sending a separate PR to update 'src/lib' or https://github.com/microsoft/TypeScript-DOM-lib-generator

[typescript-bot]

The TypeScript team hasn't accepted the linked issue #35745. If you can get it accepted, this PR will have a better chance of being reviewed.

[Josh-Cena]

@niieani Please note that (1) mutable arrays are subtypes of immutable ones (2) you can't guarantee the existence of any key in the iterable, so this is unsound, as mentioned in #35745 (comment).

[niieani]

@Josh-Cena that's unfortunate. Is there any way to only target const tuples in the type system, without affecting mutable Arrays?

EDIT: ooh, what if I did check for extends Array<any> ? never : ... ?

[Josh-Cena]

No, you can only target fixed length tuples—for example, add ten overloads for [[K, V]], [[K, V], [K, V]], etc. But there's not type to represent "any fixed-length tuple"

[sandersn]

Given that the design is still in flux, I'd recommend opening a new issue to continue discussion. Then this PR should be either a draft or closed.

[niieani]

@sandersn @Josh-Cena I've addressed the issue. Here's a playground showing that it works correctly in all cases.
With the updated typings, only objects created from const tuples will have their shape known, as those are guaranteed to be present and thus sound.

Non-const tuples and regular arrays fallback to the old (currently released) behavior, i.e. they're either a Record if values are of the same type, or any.

[sandersn]

Can you still open an issue to track this? All the issues you reference are closed, which makes me think that they're missing something new about what you've done. In particular, I'd like to see @RyanCavanaugh 's opinion about your last comment on #35745 .

[niieani]

@sandersn I can create an issue. I've discovered an unsoundness in my last implementation.
Let me see if I can fix it first, and I'll get back to you and ping Ryan.

[niieani]

Okay, I've solved the soundness issue, but it turned out to be a bit complex.

Here's the playground.

@sandersn @RyanCavanaugh Perhaps there's an easier way to type this? Would anyone have suggestions on how to simplify this?

I'll hold off on updating the PR with the sound solution, until I get a green light.

EDIT: Opened #50379.

[niieani]

Just FYI for anyone following, I've finally gotten around to publishing an NPM package with the strict Object.fromEntries typings. It doesn't suffer from any unsoundness as far as I can tell and is fully compatible with the regular Object.fromEntries.
See nesity-types.