The case of Object.fromEntries I believe this is different from the Object.keys and Object.entries problem. In the Object.keys and Object.entries case, it would be incorrect for TypeScript to assume that the only keys on the object are limited to those on the type. In the case of Object.fromEntries however, TypeScript can guarantee that the Object it returns will at least have the set of keys it knows about on the incoming tuple array.

@wucdbm I recommend removing the Object.entries case from this request as that cannot change without breaking TypeScript type safety (see the issue about Object.keys you linked). I think Object.fromEntries can be fixed though.

Personal stab at typing it, it gets kind of complex, not sure if there is a simpler approach 😕

type UnionToIntersection<T> = (T extends T ? (p: T) => void : never) extends (p: infer U) => void ? U : never
type FromEntries<T extends readonly [PropertyKey, any]> = T extends T ? Record<T[0], T[1]> : never;
type Flatten<T> = {} & {
  [P in keyof T]: T[P]
}

function fromEntries<V extends PropertyKey, T extends [readonly [V, any]] | Array<readonly [V, any]>>(entries: T): Flatten<UnionToIntersection<FromEntries<T[number]>>> {
  return null!;
}

let o = fromEntries([["A", 1], ["B", "1"], [1, true]])
// let o: {
//     A: number;
//     B: string;
//     1: boolean;
// }

Playground Link

Or without any helper types (can't wait for the SO questions as to what this does 😂):

function fromEntries<V extends PropertyKey, T extends [readonly [V, any]] | Array<readonly [V, any]>>(entries: T):
  (((T[number] extends infer Tuple ? Tuple extends [PropertyKey, any] ? Record<Tuple[0], Tuple[1]> : never : never) extends
    infer FE ? (FE extends FE ? ((p: FE) => void) : never) extends (p: infer U) => void ? U : never : never) extends 
    infer R ? { [P in keyof R] : R[P] }: never)
    
  {
  
  return null!;
}

let o = fromEntries([["A", 1], ["B", "1"], [1, true]])
// let o: {
//     A: number;
//     B: string;
//     1: boolean;
// }

Playground Link

@MicahZoltu Fair enough.

In that case, I guess the Object.entries problem could be solved by a 3rd-party library that implements runtime extraction based on a type/interface, simply for the sake of not writing these functions by hand.

For example,

import {entries} from 'some-lib';

const someTypeEntriesOnly = entries<SomeType>(object);

would generate (once per type) a function that takes an object and returns the fields of SomeType only by calling Object.entries(object) and then calling .filter to only return the subset contained in SomeType. Or something like that. Assuming the Object.fromEntries proposal is accepted, this would work perfectly well for us, although in our particular case we wouldn't need the .filter overhead from such a library as the values passed around in our app never satisfy two separate types. At least so far.
But then again, this seems to fall outside of the intended use of TypeScript itself.

I stumbled upon https://www.npmjs.com/package/typescript-is and #14419 today. Could use its source code as a starting point if 14419 is accepted and its easy to plug into TS for code generation.

WDYT?

Something similar to typescript-is could work for generating code that "loops over all of the keys known at compile time, but not over all of the keys on the object".

Original comment updated.

Furthermore, due to #31393 imo it makes sense to go with K extends string rather than K extends PropertyKey for the time being, as that shouldn't hurt anybody, until #31393 is resolved.

fromEntries<K extends string, T = any>(entries: Iterable<readonly [K, T]>): { [k in K]: T };

What is the status on this? fromEntries seems like it would only benefit from @wucdbm's type signature above.

Often you can achieve the desired result with a pattern like this:

const fruits = [ 'apple', 'banana', 'cherry' ] as const
type Fruits = (typeof fruits)[number]
type FruitBasket = Record<Fruits, number>

function countFruits(fruitBasket: FruitBasket) {
    let totalFruits = 0
    for (const fruit of fruits) {
        totalFruits += fruitBasket[fruit]
    }
    return totalFruits
}

countFruits({ apple: 5, banana: 7, cherry: 3 }) // returns: 15

const produceBasket = { apple: 5, banana: 2, cherry: 1, asparagus: 7 }
countFruits(produceBasket) // returns: 8; note it didn't count the asperagus

@MicahZoltu Good point. That could come in handy in several of the use-cases the .entries typing proposal was trying to solve.

Does anybody know a use-case where fromEntries<K extends string, T = any>(entries: Iterable<readonly [K, T]>): { [k in K]: T }; will be wrong or interfere with other features or break existing code?

Can TypeScript at least provide a type-safe version of Object.entries for Record<K, V>?

Here keys are known to be of K, but the current signature treats them as strings.