Mapped tuples types iterates over all properties

lemoinem commented 6 years ago

TypeScript Version: 3.2.0-dev.20181019

Search Terms: mapped tuples reify

Code

type Foo = ['a', 'b'];
interface Bar
{
    a: string;
    b: number;
}

type Baz = { [K in keyof Foo]: Bar[Foo[K]]; }; // Expected Baz to be [string, number]

Expected behavior: Baz should be [string, number]

Actual behavior: Type '["a", "b"][K]' cannot be used to index type 'Bar'.

Playground Link: https://www.typescriptlang.org/play/index.html#src=type%20Foo%20%3D%20%5B'a'%2C%20'b'%5D%3B%0D%0Ainterface%20Bar%0D%0A%7B%0D%0A%09a%3A%20string%3B%0D%0A%09b%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Atype%20Baz%20%3D%20%7B%20%5BK%20in%20keyof%20Foo%5D%3A%20Bar%5BFoo%5BK%5D%5D%3B%20%7D%3B%20%2F%2F%20Expected%20Baz%20to%20be%20%5Bstring%2C%20number%5D%0D%0A%0D%0Atype%20WorkingBaz%20%3D%20%7B%20%5BK%20in%20Exclude%3Ckeyof%20Foo%2C%20keyof%20any%5B%5D%3E%5D%3A%20Foo%5BK%5D%20extends%20keyof%20Bar%20%3F%20Bar%5BFoo%5BK%5D%5D%20%3A%20never%3B%20%7D%20%26%20%7B%20length%3A%20Foo%5B'length'%5D%3B%20%7D%20%26%20any%5B%5D%3B

Given the Mapped tuple types feature (#25947). I'd expect the code above to work cleanly.

However, I still need to do:

type WorkingBaz = { [K in Exclude<keyof Foo, keyof any[]>]: Foo[K] extends keyof Bar ? Bar[Foo[K]] : never; } & { length: Foo['length']; } & any[];

To have an equivalent type. As far as I understand, the "K" in a mapped type on a tuple should iterate only on numeric keys of this tuple. Therefore, Foo[K] should always be a valid key for Bar...

weswigham commented 6 years ago

This is because, despite mapped types not behaving as such, keyof ["some", "tuple"] still returns 0 | 1 | "length" | ... | "whatever" instead of 0 | 1.

nabbydude commented 6 years ago

I wouldnt mind a fix for this as well. I've been encountering similar issues, but here's how I've been working around it for anyone else with this problem: (my code generalized below with Boxes)

interface Box<T> {
  value: T;
}

type UnBox<T extends Box<unknown>> = T extends Box<infer U> ? U : never;

type UnBoxTuple<T extends Box<unknown>[]> = {
  [P in keyof T]: UnBox<T[P]>;
};

Above code complains that T[P] does not satisfy the constraint Box<unknown>. My current fix has been just to manually narrow the type with a conditional like so: (Edit: looks like this format is required for using mapped tuples like this, #27351)

type UnBoxTuple<T extends Box<unknown>[]> = {
  [P in keyof T]: T[P] extends T[number] ? UnBox<T[P]> : never;
};

Trying to apply the same to @lemoinem's example didn't work at first. It seems like the mapped tuple special-case only applies to generics (try the following in ts 3.1.3 to see what I mean):

type Foo = ["a", "b"];

type GenericTupleIdentity<T extends unknown[]> = { [K in keyof T]: T[K] };
type FooIdentity = { [K in keyof Foo]: Foo[K] }

type GenericTupleIdentityTest = GenericTupleIdentity<Foo> // ["a", "b"]
type FooIdentityTest = FooIdentity // a Foo-like object no longer recognised as a tuple

Not sure if this inconsistency is intended or not. Abstracting-out Foo and Bar and adding a manual type-narrower gets us:

type Bazify<B, F extends (keyof B)[]> = {
  [K in keyof F]: F[K] extends F[number] ? B[F[K]] : never;
};

Which can then be called with Bazify<Bar, Foo> (or use type Baz = Bazify<Bar, Foo>; to keep existing-code-changes to a minimum)

ahejlsberg commented 6 years ago

The issue here is that we only map to tuple and array types when we instantiate a generic homomorphic mapped type for a tuple or array (see #26063). We should probably also do it for homomorphic mapped types with a keyof T where T is non-generic type.

phiresky commented 6 years ago

Just stumbled on what I assume is the same issue:

type n1 = [1, 2, 3]
type n2t<T> = {[k in keyof T]: 4}

type n2 = { [k in keyof n1]: 4 } // { length: 4, find: 4, toString: 4, ...}
type n2b = n2t<n1> // [4, 4, 4] as expected

I would expect n2 to behave like n2b.

phiresky commented 6 years ago

This also means that these constructs don't work:

type Test1<S extends number[]> = Record<number, "ok">[S[keyof S]];

type Test2<S extends [0, 1, 2]> = Record<number, "ok">[S[keyof S]];

The second one should definitely work. This means that it's impossible to map tuples to other tuples with a method that requires the value type of the input tuple to be known to extend something (e.g. number as above)

ksaldana1 commented 5 years ago

@lemoinem You can get your current example to narrow correctly and avoid the behavior @weswigham mentioned with a couple of helper conditional types. Note: this comes with some not so great drawbacks.. You lose all array prototype methods and properties, which for my current use case--messing with React hooks--that tradeoff isn't the worst thing in the world.

export type ArrayKeys = keyof any[];
export type Indices<T> = Exclude<keyof T, ArrayKeys>;

type Foo = ['a', 'b'];

interface Bar {
  a: string;
  b: number;
}

type Baz = { [K in Indices<Foo>]: Bar[Foo[K]] }; // type is { "0": string, "1": number }

The way this type ends up formatting isn't the greatest, but it ultimately maps to some of your desired outcomes. I am having issues around some constructs I thought would work, similar to @phiresky 's examples. I will get some better examples together and document those, but for now just wanted to provide a bit of a workaround.

lemoinem commented 5 years ago

@ksaldana1 Thanks, nice idea! Actually my own WorkingBaz is a pretty good workaround as well, if I can say so myself:

type WorkingBaz = { [K in Exclude<keyof Foo, keyof any[]>]: Bar[Foo[K]]; } & { length: Foo['length']; } & any[]

It avoids the drawback of losing the Array prototype's methods (only their typing info, which are already much less useful on heterogeneous tuples...). Although it's not recognized as [string, number], as far as I can tell, it's still an almost structurally equivalent type: { "0": string; "1": number; } & { length: 2; } & any[].

But I'd still expect this to work out of the box and produce the correct [string, number] type.

WhiteAbeLincoln commented 5 years ago

I'm also seeing the same bug. I was about to log an issue, but I saw this one in the related issues page.

For reference, the code I'm experiencing this bug with: Search Terms: tuple mapped type not assignable Code

type Refinement<A, B extends A> = (a: A) => a is B
// we get the error `Bs[k] does not satisfy the constraint 'A'. Type A[][k] is not assignable to type A`
type OrBroken = <A, Bs extends A[]>(...preds: { [k in keyof Bs]: Refinement<A, Bs[k]> }) => Refinement<A, Bs[number]>
// same (well similar, [A, A, A][k] is not assignable vs A[][k] not assignable) error
type OrBroken1 = <A, Bs extends [A, A, A]>(...preds: { [k in keyof Bs]: Refinement<A, Bs[k]> }) => Refinement<A, Bs[number]>
// if we don't map over the type we don't receive the error
type OrWorks = <A, Bs extends A[]>(...preds: { [k in keyof Bs]: Refinement<A, Bs[0]> }) => Refinement<A, Bs[number]>
type OrWorks1 = <A, Bs extends A[]>(...preds: { [k in keyof Bs]: Refinement<A, Bs[number]> }) => Refinement<A, Bs[number]>

Expected behavior: When mapping over a tuple type Bs where every element extends some type A, the mapped type Bs[k] should be assignable to A. In other words, OrBroken in the above example should not give an error Actual behavior: We recieve the error Bs[k] does not satisfy the constraint 'A'. Type A[][k] is not assignable to type A

Playground Link: link

augustobmoura commented 5 years ago

You could just filter for number properties:


type Foo = ['a', 'b'];
interface Bar
{
    a: string;
    b: number;
}

// Inverse of Exclude<>
type FilterOnly<T, N> = T extends N ? T : never;

type Baz = {
  [K in FilterOnly<keyof Foo, number>]: Bar[Foo[K]];
};

lemoinem commented 5 years ago

I think we have enough and various workarounds and comments from the TS team identifying the root issue. If you have the same issue, may I suggest you add a thumbs up/+1 reaction to the initial comment (and subscribe to the issue so you will know when this is finally fixed) instead of commenting "Me too".

This will prevent spamming everyone in the thread. Thank you very much. (I'm still eagerly waiting for a fix to this ;) )

ccorcos commented 5 years ago

Hey there, I'm running into this issue, except I'm using a generic tuple type instead of a statically declared tuple.

type PropertyType = "string" | "number" | "boolean"

type PropertyValueTypeMap = {
    string: string, 
    number: number, 
    boolean: boolean
}

type Args<A extends Array<PropertyType>> = {
    // ERROR: Type 'A[I]' cannot be used to index type 'PropertyValueTypeMap'.
    [I in keyof A]: PropertyValueTypeMap[A[I]] 
}

// RESULT: type A = [string, number]
type A = Args<["string", "number"]>

playground

@augustobmoura's FilterOnly approach doesn't work. @ksaldana1's Exclude<keyof Foo, keyof any[]> approach also does not work.

ccorcos commented 5 years ago

Considering that this works:

type Args<A extends Array<PropertyType>> = {
    0: PropertyValueTypeMap[A[0]]
    1: PropertyValueTypeMap[A[1]]
    2: PropertyValueTypeMap[A[2]]
}

... I would have expected this to work, but it doesn't:

type Args<A extends Array<PropertyType>> = {
    [K in keyof A]: K extends number ? PropertyValueTypeMap[A[K]] : never
}

Also tried this...

type Args<A extends Array<PropertyType>> = {
    [K in keyof A]: K extends keyof Array<any> ?  never : PropertyValueTypeMap[A[K]]
}

tao-cumplido commented 4 years ago

@ccorcos I just had the same problem, solved it like this

type PropertyType = "string" | "number" | "boolean"

type PropertyValueTypeMap = {
    string: string, 
    number: number, 
    boolean: boolean
}

type Args<A extends Array<PropertyType>> = {
    [I in keyof A]: A[I] extends PropertyType ? PropertyValueTypeMap[A[I]] : never;
}

// RESULT: type A = [string, number]
type A = Args<["string", "number"]>

treybrisbane commented 4 years ago

I've frequently been bitten by this. It's come up enough for me that I now usually avoid using mapped types with tuples and instead resort to arcane recursive types to iterate over them. I'm not a fan of doing this, but it's proven to be a much more reliable means of tuple transformations. 😢

@ahejlsberg from your comment it's not clear how complex this is to solve. Is the fix simple?

If the team is looking to get help from the community on this one, it may help to have a brief outline of the necessary work if possible (e.g. relevant areas of the compiler, any necessary prework, gotchas, etc). 🙂

treybrisbane commented 4 years ago

Just as an aside... Flow has an entirely separate utility type for mapping over arrays/tuples. Given TypeScript has gone with a syntatic approach to mapped types thus far, I can't help but wonder: Should we have separate, dedicated syntax for array/tuple mapping? 🤔

An example might be simply using square brackets instead of curlies, e.g. [[K in keyof SomeTuple]: SomeTuple[K]]

I just can't shake the feeling that trying to specialise the behaviour of the existing mapped types for arrays/tuples may create more problems than it solves. This very issue is a consequence of trying to do it. There are also cases like "I want to map over a tuple type from an object perspective" that don't have clear answers to me, but that's an entirely separate discussion.

Anyway, I'm not sure if dedicated syntax has already been considered and rejected. I'm more just throwing it out there in case it hasn't. 🙂

maraisr commented 4 years ago

@ccorcos I just had the same problem, solved it like this

type PropertyType = "string" | "number" | "boolean"

type PropertyValueTypeMap = {
  string: string, 
  number: number, 
  boolean: boolean
}

type Args<A extends Array<PropertyType>> = {
    [I in keyof A]: A[I] extends PropertyType ? PropertyValueTypeMap[A[I]] : never;
}

// RESULT: type A = [string, number]
type A = Args<["string", "number"]>

Further that @tao-cumplido would it be possible to extend that so that the length of infered from a keyof? eg:

type Things = 'thing-a' | 'thing-b';

type Test = Args<string, Things>; // [string, string]
type Test2 = Args<string | number, Things>; // [string | number, string | number ]
type Test2 = Args<string, Things | 'thing-3'>; // [string string, string]

declare const test:Args<string, Things> = ['a', 'b'];

dgreensp commented 4 years ago

I've been trying to come up with a way to map over a type T that could be an array or a tuple, without inserting an extra conditional over T[i], which can get in the way. Here's what I've got:

interface Box<V = unknown> {
    value: V
}
function box<V>(value: V) {
    return { value }
}

type Unbox<B extends Box> = B['value']

type NumericKey<i> = Extract<i, number | "0" | "1" | "2" | "3" | "4"> // ... etc

type UnboxAll<T extends Box[]> = {
    [i in keyof T]: i extends NumericKey<i> ? Unbox<T[i]> : never
}

declare function unboxArray<T extends Box[]>(boxesArray: T): UnboxAll<T>
declare function unboxTuple<T extends Box[]>(...boxesTuple: T): UnboxAll<T>

const arrayResult = unboxArray([box(3), box('foo')]) // (string | number)[]
const tupleResult = unboxTuple(box(3), box('foo')) // [number, string]

So far, I haven't been able to find a variant that works for any numeric key, without the hardcoding ("0" | "1" | "2" | ...). Typescript is very sensitive about what goes into the mapped type in UnboxAll. If you mess with the [i in keyof T] part at all, it stops being to instantiate arrays and tuples with the mapped type. If you try to use keyof T in the conditional that begins i extends..., or do anything too fancy, TypeScript is no longer convinced that T[i] is a Box, even if you are strictly narrowing i.

As stated before, I am specifically trying to avoid testing T[i] extends Box, because in my case this conditional appears downstream as unevaluated. Really if T extends Box[] and I'm using a homomorphic mapped type to transform arrays and tuples, there should be a way to use T[i] and have it be known to be a Box without introducing a conditional. Or, it should be at least be possible/convenient to extract the suitable indices so that the conditional can be on the indices.

dgreensp commented 4 years ago

Actually, the following totally works for my purposes:

interface Box<V = unknown> {
    value: V
}
function box<V>(value: V) {
    return { value }
}

type Unbox<B extends Box> = B['value']

type UnboxAll<T extends Box[]> = {
    [i in keyof T]: Unbox<Extract<T[i], T[number]>> // !!!
}

declare function unboxArray<T extends Box[]>(boxesArray: T): UnboxAll<T>
declare function unboxTuple<T extends Box[]>(...boxesTuple: T): UnboxAll<T>

const arrayResult = unboxArray([box(3), box('foo')]) // (string | number)[]
const tupleResult = unboxTuple(box(3), box('foo')) // [number, string]

I just needed to test T[i] inside the call to Unbox<...> to avoid an extra conditional that could stick around unevaluated. I'm aware that Extract is itself a conditional. Somehow this code works out better (for reasons not visible in the example) than if I wrote T[i] extends T[number] ? Unbox<T[i]> : never. I hope this helps someone else.

dgreensp commented 4 years ago

This is still something that irks me daily, because I have a lot of code that maps over array types, whether or not they are tuples. When mapping over X extends Foo[], you can't assume X[i] is a Foo. You need a conditional, every time, making the code more verbose.

For example:

type Box<T = unknown> = { value: T }

type Values<X extends Box[]> = {
    [i in keyof X]: Extract<X[i], Box>['value'] // Extract is needed here
}

type MyArray = Values<{value: number}[]> // number[]
type MyTuple = Values<[{value: number}, {value: string}]> // [number, string]

It's worth noting that the behavior shown in MyArray and MyTuple is already magical. TypeScript is not literally transforming every property, just the positional ones.

While I have no knowledge of the internals here, my guess is that the actual mapping behavior could be changed rather easily; the problem is getting X[i] to have the appropriate type.

It would be really nice if this code would just work:

type Values<X extends Box[]> = {
    [i in keyof X]: X[i]['value']
}

The question is, presumably, on what basis can i be taken to have type number rather than keyof X to the right of the colon? And then, when we go to do the actual mapping on some X, do we somehow make sure to always ignore the non-positional properties, in order to be consistent with this? (Note that the current behavior is already pretty weird if the type passed as X is an array that also has non-positional properties, so I don't think we need to worry overly much about that case.)

Here is perhaps a novel idea, not sure if it is useful, but I wonder if it would be harder or easier to modify the compiler so that this code works for mapping arrays and tuples:

type Values<X extends Box[]> = {
    [i in number]: X[i]['value']
}

As before, the intent would be for this to work on pure arrays and pure tuples X, and do something sensible on non-pure types. It seems like there is no more problem of making sure i has the correct type to the right of the colon, here. The problem would presumably be recognizing this pattern as mapping over X.

dgreensp commented 4 years ago

Alternatively, just to throw it out there, there could be a new keyword posof that means "positional properties of." Then you could write[i in posof X]. I'm not sure introducing a new keyword is the right solution, but I thought I'd mention it. Presumably it would solve any difficulties of i having the right type and doing the array and tuple mapping without having to impose new semantics on existing mapped types that might break compatibility or be too complex.

DavidGoldman commented 4 years ago

@ksaldana1 Thanks, nice idea! Actually my own WorkingBaz is a pretty good workaround as well, if I can say so myself:
type WorkingBaz = { [K in Exclude<keyof Foo, keyof any[]>]: Bar[Foo[K]]; } & { length: Foo['length']; } & any[]
It avoids the drawback of losing the Array prototype's methods (only their typing info, which are already much less useful on heterogeneous tuples...). Although it's not recognized as [string, number], as far as I can tell, it's still an almost structurally equivalent type: { "0": string; "1": number; } & { length: 2; } & any[].

But I'd still expect this to work out of the box and produce the correct [string, number] type.

Trying to generalize this (at least the first part):

export type ArrayKeys = keyof unknown[];
export type TupleKeys<T extends unknown[]> = Exclude<keyof T, ArrayKeys>;
type PickTuple<T extends Record<string, any>, TupleT extends Array<keyof T>> = {
  [K in TupleKeys<TupleT>]:T[TupleT[K]];
};

gives Type 'TupleT[K]' cannot be used to index type 'T'

But this seems to workaround that:

export type ArrayKeys = keyof unknown[];
export type TupleKeys<T extends unknown[]> = Exclude<keyof T, ArrayKeys>;
type PickTuple<T extends Record<string, any>, TupleT extends Array<keyof T>> = {
  [K in TupleKeys<TupleT>]:
    TupleT[K] extends keyof T ? T[TupleT[K]] : never;
};

giving:

type PickTuple<T extends Record<string, any>, TupleT extends Array<keyof T>> = {
  [K in TupleKeys<TupleT>]:
    TupleT[K] extends keyof T ? T[TupleT[K]] : never & { length: TupleT['length']; } & unknown[];
};

EDIT: I just saw this comment which provides something similar but manages to keep the tuple (since it filters for number properties like mentioned here):

type Bazify<B, F extends (keyof B)[]> = {
  [K in keyof F]: F[K] extends F[number] ? B[F[K]] : never;
};

treybrisbane commented 3 years ago

I just discovered this potential workaround as of TypeScript 4.1:

type BoxElements<Tuple extends readonly unknown[]> = {
  [K in keyof Tuple]: K extends `${number}` ? Box<Tuple[K]> : Tuple[K]
};

I haven't tested it extensively, but seems to work for my current use case! 🙂

jcalz commented 3 years ago

@ahejlsberg

We should probably also do it for homomorphic mapped types with a keyof T where T is non-generic type.

And maybe also where T is a generic type constrained to an array/tuple type like T extends Array<X>?

thw0rted commented 3 years ago

At the very top of the thread, @weswigham commented:

keyof ["some", "tuple"] still returns 0 | 1 | "length" | ... | "whatever" instead of 0 | 1.

Did this behavior change at some point? Per this playground, keyof [string, string] types as number | keyof [string, string]. Tuples should definitely type with numeric-literal keys, rather than number, right? Does this need its own issue, possibly as a regression?

treybrisbane commented 3 years ago

@thw0rted I don't believe they have numeric-literal keys, but rather numeric-string-literal keys. In your case, I believe keyof [string, string] would be number | "0" | "1".

Playground example (hover over foo to see its type).

thw0rted commented 3 years ago

OK, looks like what was confusing was that now the language service emits "keyof [string,string]" instead of the whole explicit litany of Array member functions, unless you remove one of them as in your example. Check the Asserts tab of this Bug Workbench -- it shows

type TT1 = number | keyof [string, string]
type TT2 = number | "0" | "1" | "length" | "toLocaleString" | "pop" | "push" | "concat" | "join" | "reverse" | "shift" | "slice" | "sort" | "splice" | "unshift" | "indexOf" | "lastIndexOf" | ... 14 more ... | "includes"

You can also open that Workbench and change around TS versions. There was a change at some point. The output above is from 4.2.3, but in 4.1.5, and 4.0.5, they both have the long spelled-out list (minus "toString" for TT2 of course). Not sure if I'd call it a "regression", but there has been a change.

Kyasaki commented 3 years ago

I came here because I needed some way of using an object's entries, while not caring at all it is a tuple or a record. I got stuck when I tried to define a type matching any property value of that object. It looks like this:

const someValueInEntriesOf = <TSubject>(subject: TSubject): TSubject[keyof TSubject] => {...}

This is where I realized why I could not: TSubject[keyof TSubject] would result in the inclusion of the Array prototype keys when an array was providen, while the Object.keys method would not.

I did a little investigation and summarized things below:

Subjects

// Types
type tuple = [number, number[], string, boolean[][]]
type array = string[]
type record = {zero: 0, one: 1, two: 2, three: 3}

// Subjects
const tupleSubject: tuple = [0, [1], 'foo', [[true]]]
const arraySubject: array = ['zero', 'one', 'two', 'three']
const recordSubject: record = {zero: 0, one: 1, two: 2, three: 3}

Fetch subject key type

console.log(Object.keys(tupleSubject)) // logs <["0", "1", "2", "3"]>, as expected. BTW Object.keys returns <string[]> instead of <(keyof typeof arraySubject)[]>.
type tupleKeyofKeys = keyof tuple // resolves as <number | keyof tuple>, why does it include <number>? And why does <keyof tuple> is made of itself anyway? 
type tupleRealKeys = Exclude<keyof tuple, keyof []> // resolves as <"0" | "1" | "2" | "3">, fixes the issue.

console.log(Object.keys(arraySubject)) // logs <["0", "1", "2", "3"]>, as expected. BTW Object.keys returns <string[]> instead of <(keyof typeof arraySubject)[]>.
type arrayKeyofKeys = keyof array // resolves as <number | keyof array>, why does it include <keyof array>, is <number> not sufficient?
type arrayRealKeys = number // using <Exclude<keyof array, keyof []>> resolves as <never> :/

console.log(Object.keys(recordSubject)) // logs <["zero", "one", "two", "three"]>, as expected. BTW Object.keys returns string[] instead of <(keyof typeof recordSubject)[]>.
type recordKeyofKeys = keyof record // resolves as <keyof record>, which further resolves as <"zero" | "one" | "two" | "three">, good.
type recordRealKeys = Exclude<keyof record, keyof []> // resolves as <"zero" | "one" | "two" | "three">, good too.

Fetch one of the subject's items type

Fetch one of the TUPLE's items type

type tupleKeyAccess_inRange = tuple[1] // resolves as <number[]>, good
type tupleKeyAccess_outOfRange = tuple[4] // throws <Tuple type 'tuple' of length '4' has no element at index '4'.ts(2493)>, good.
type tupleKeyAccess_generic = tuple[number] // resolves as <string | number | number[] | boolean[][]>, but is strictly incorrect. 4 is a number and cannot index the tuple type, see tupleKeyAccess_outOfRange.
type tupleKeyAccess_keyofKeys = tuple[tupleKeyofKeys] /* resolves as (sorry for your eyes):
<string | number | number[] | boolean[][] | (() => IterableIterator<string | number | number[] | boolean[][]>) | (() => {
    copyWithin: boolean;
    entries: boolean;
    fill: boolean;
    find: boolean;
    findIndex: boolean;
    keys: boolean;
    values: boolean;
}) | ... 30 more ... | (<A, D extends number = 1>(this: A, depth?: D | undefined) => FlatArray<...>[])>.
This is not expected behaviour, seems like tupleKeyofKeys includes Object.getPrototypeOf(tupleSubject) keys. */
type tupleKeyAccess_realKeys = tuple[tupleRealKeys] // resolves as <string | number | number[] | boolean[][]>, good.

Fetch one of the ARRAY's items type

type arrayKeyAccess_inRange = array[1] // resolves as <string>, as using strict mode, I expected <string | undefined>.
type arrayKeyAccess_outOfRange = array[4] // resolves as <string>, as using strict mode, I expected <string | undefined>.
type arrayKeyAccess_generic = array[number] // resolves as <string>, as using strict mode, I expected <string | undefined>.
type arrayKeyAccess_keyofKeys = array[arrayKeyofKeys] /* resolves as (sorry for your eyes):
<string | number | (() => IterableIterator<string>) | (() => {
    copyWithin: boolean;
    entries: boolean;
    fill: boolean;
    find: boolean;
    findIndex: boolean;
    keys: boolean;
    values: boolean;
}) | ... 30 more ... | (<A, D extends number = 1>(this: A, depth?: D | undefined) => FlatArray<...>[])>
This is not expected behaviour, seems like arrayKeyofKeys includes Object.getPrototypeOf(arraySubject) keys. */
type arrayKeyAccess_realKeys = array[arrayRealKeys] // resolves as string, good

Fetch one of the RECORD's items type

type recordKeyAccess_inRange = record['one'] // resolves as <1>, good.
type recordKeyAccess_outOfRange = record['four'] // throws <Property 'four' does not exist on type 'record'.ts(2339)>, good.
type recordKeyAccess_generic = record[string] // throws <Type 'record' has no matching index signature for type 'string'.ts(2537)>, very good!!
type recordKeyAccess_keyofKeys = record[recordKeyofKeys] // resolves as <0 | 1 | 2 | 3>. Still good there.
type recordKeyAccess_realKeys = record[recordRealKeys] // resolves as <0 | 1 | 2 | 3>, good good.

What went wrong (summary)

Object access/indexing is not consistant among containers in TypeScript (mostly for historic reason I suppose, some operators/features were missing at the time), specificaly among arrays, tuples and records:

Arrays allow out of range access, and do not include undefined in the item type.
Tuples prevent out of range access using raw numeric index, but allow number typed indexes, finaly allowing out of range access.
keyof arrayOrTuple includes Object.getPrototypeOf(arrayOrTuple) while Object.keys(arrayOrTuple) does not.

In the meantime, records:

prevent out of range access, or have undefined included in the item type when the keys are not precisely known ({[key: string]: itemType})
keyof record does not include Object.getPrototypeOf(record) which is consistant with Object.keys(record)

Additionaly, those are problematic too:

There is no way to distinguish a tuple from an array.
Object.keys(object) is typed string[], but should be the tuple equivalent of (keyof typeof object)[] when possible. Thus object[Object.keys(object)[0]] (where object is known to have at least one property) is not valid TypeScript until explicitely casted to keyof typeof object.

What I use now until the TypeScript lang contributors fix the thing(s)

type IsTuple<T> = T extends unknown[] ? true : false // I found no way to tell apart an array from a tuple. This line must be improved as you will see later why.
type TupleFixedKeyof<T> = IsTuple<T> extends true ? Exclude<keyof T, keyof []> : keyof T // THE fix

type tupleKeysIExpected = TupleFixedKeyof<tuple> // resolves as <"0" | "1" | "2" | "3">, fixes tuples.
type arrayKeysIDidNotExpected = TupleFixedKeyof<array> // resolves as never... Use TupleFixedKeyof wisely (only when not using arrays, only tuples and records) until IsTuple exists natively in TypeScript some way.
type recordKeysIExpected = TupleFixedKeyof<record> // resolves as <keyof record> which further resolves as <"zero" | "one" | "two" | "three">, behaviour is correct for records.

Andarist commented 2 years ago

I've been digging into this a little bit with the debugger and for what it is worth - I think this could be fixed if only a mapped type like this could be "resolved" (to not call it as instantiation) in getTypeFromMappedTypeNode that is called by checkMappedType.

If only we could recognize there that the constraint for the iteration refers to a tuple type and that mapping would be homomorphic then the assigned links.resolvedType would be computed as a tuple type. This in turn would fix places like propertiesRelatedTo because both source and target would just correctly be recognized as tuples. At the moment the target (the mapped type) is not recognized there so it's roughly treated as an object type and all its properties are checked there (and not only numerical ones).

I've tried to accomplish this - but I'm not sure how to best "resolve" this mapped type, I've looked through what instantiateType, getObjectTypeInstantiationand instantiateMappedType (as well as getNonMissingTypeOfSymbol) but it's unfortunately over my head at the moment and I don't know how to reuse their logic or how to apply a different one based on their inner workings.

jcalz commented 2 years ago

If any part of this question has to do with generic T (as some comments mention), then that part has been fixed by #48837.

The part where the type you're iterating over is non-generic remains, though.

Andarist commented 2 years ago

The part where the type you're iterating over is non-generic remains, though.

The first given repro in this thread doesn't use a generic mapped type - so I would say that this issue is still sound despite the improvements made in the #48837. Luckily there is also a fix for this issue in https://github.com/microsoft/TypeScript/pull/48433 but it still awaits the review.

schummar commented 2 years ago

To expand on @Kyasaki's workaround a bit: I found it is possible to distinguish between tuples and arrays like this:

type GetKeys<T> = T extends unknown[]
  ? T extends [] // special case empty tuple => no keys
    ? never
    : "0" extends keyof T // any tuple with at least one element
    ? Exclude<keyof T, keyof []>
    : number // other array
  : keyof T; // not an array

type TupleKeys = GetKeys<[1, 2, 3]>; // "0" | "1" | "2"
type EmptyTupleKeys = GetKeys<[]>; // never
type ArrayKeys = GetKeys<string[]>; // number
type RecordKeys = GetKeys<{ x: 1; y: 2; z: 3 }>; // "x" | "y" | "z"

type GetValues<T> = T[GetKeys<T> & keyof T];

type TupleValues = GetValues<[1, 2, 3]>; // 1 | 2 | 3
type EmptyTupleValue = GetValues<[]>; // never
type ArrayValues = GetValues<string[]>; // string
type RecordValues = GetValues<{ x: 1; y: 2; z: 3 }>; // 1 | 2 | 3

Not sure this is bulletproof, but at least solves my use case nicely. 😉

rubick24 commented 1 year ago

I'm running into a similar issue:

type MapTuple <T extends any[]> = {
  [K in keyof T]: {
    value: T[K]
  }
}

type Foo<T extends (...args: any[]) => any> = MapTuple<Parameters<T>>
const f = <T extends (...args: any[]) => any>(a: Foo<T>): Parameters<T> => {
  return a.map(v => v.value)
}
// 'map' inferred as { value: Parameters<T>[never]; } and not callable.

Is there a work around in this case? 👀

Andarist commented 1 year ago

@Deadalusmask I feel like your issue is likely related to another issue

rene-leanix commented 1 year ago

Is the following issue related to this one as well? It shows that inlining a type mapper can lead to iteration over all array properties and methods.

type InnerMapper<Attributes> = {
  [Index in keyof Attributes]: Attributes[Index];
};

//--- The inlined mapper MapperA2 yields different results when the attributes are handed in via an interface

interface AttributeWrapper {
  attributes: string[];
}

type MapperA1<Wrapper extends AttributeWrapper> = InnerMapper<Wrapper['attributes']>;

type MapperA2<Wrapper extends AttributeWrapper> = {
  [Index in keyof Wrapper['attributes']]: Wrapper['attributes'][Index];
};

type ResultA1 = MapperA1<{ attributes: ['type', 'id'] }>;
  // ^? type ResultA1 = ["type", "id"]
type ResultA2 = MapperA2<{ attributes: ['type', 'id'] }>;
  // ^? type ResultA2 = { [x: number]: "type" | "id"; 0: "type"; 1: "id"; length: 2; toString: () => string; ...

//--- Results of both mappers are identical when attributes are handed in directly

type MapperB1<Attr extends string[]> = InnerMapper<Attr>;

type MapperB2<Attr extends string[]> = {
  [Index in keyof Attr]: Attr[Index];
};

type ResultB1 = MapperB1<['type', 'id']>;
  // ^? type ResultB1 = ["type", "id"]
type ResultB2 = MapperB2<['type', 'id']>;
  // ^? type ResultB1 = ["type", "id"]

Compiler Options

```json { "compilerOptions": { "strict": true, "noImplicitAny": true, "strictNullChecks": true, "strictFunctionTypes": true, "strictPropertyInitialization": true, "strictBindCallApply": true, "noImplicitThis": true, "noImplicitReturns": true, "alwaysStrict": true, "esModuleInterop": true, "declaration": true, "target": "ES2017", "jsx": "react", "module": "ESNext", "moduleResolution": "node" } } ```

Playground Link: Provided

akutruff commented 1 year ago

New Workaround for Tuples

Ran into this too, but I found a more concise and simpler work around using recursive types with the bonus of tail-recursion optimization:

Fix:

type TupleKeysToUnion<T extends readonly unknown[], Acc = never> = T extends readonly [infer U, ...infer TRest]
  ? TupleKeysToUnion<TRest, Acc | U>
  : Acc;

export type MapOfTupleKeys<T extends readonly unknown[]> = { [K in Extract<TupleKeysToUnion<T>, PropertyKey>]: K };

Example that turns a tuple into a map of keys with itself:

type Example = ['a', 'b', 'c'];
type KeysAsUnion = TupleKeysToUnion<Example>;
//result: "a" | "b" | "c"

type MappedResult = MapOfTupleKeys<Example>;
// type MappedResult = {
//   a: "a";
//   b: "b";
//   c: "c";
// }

b2whats commented 1 year ago

New Workaround for Tuples

Ran into this too, but I found a more concise and simpler work around using recursive types with the bonus of tail-recursion optimization:

Fix:
type TupleKeysToUnion<T extends readonly unknown[], Acc = never> = T extends readonly [infer U, ...infer TRest]
  ? TupleKeysToUnion<TRest, Acc | U>
  : Acc;

export type MapOfTupleKeys<T extends readonly unknown[]> = { [K in Extract<TupleKeysToUnion<T>, PropertyKey>]: K };
Example that turns a tuple into a map of keys with itself:
type Example = ['a', 'b', 'c'];
type KeysAsUnion = TupleKeysToUnion<Example>;
//result: "a" | "b" | "c"

type MappedResult = MapOfTupleKeys<Example>;
// type MappedResult = {
//   a: "a";
//   b: "b";
//   c: "c";
// }

Very much letters

type Example = ['a', 'b', 'c'];
type KeysAsUnion = Example[number];

type MapOfTupleKeys<T extends [...any]> = {
  [K in T[number]]: K
}
type MappedResult = MapOfTupleKeys<Example>;

13OnTheCode commented 11 months ago

I've come up with a more concise and straightforward method that should be able to address all possible scenarios.

Playground

type GetKeys<T> = (
  T extends readonly unknown[]
    ? T extends Readonly<never[]>
      ? never
      : { [K in keyof T]-?: K }[number]
    : T extends Record<PropertyKey, unknown>
      ? { [K in keyof T]-?: K extends number | string ? `${K}` : never }[keyof T]
      : never
)

type TupleKeys = GetKeys<['hello', 'world']> // "0" | "1"

type ArrayKeys = GetKeys<string[]> // number

type EmptyTupleKeys = GetKeys<[]> // never

type RecordKeys = GetKeys<{ a: 1, b: 2, 100: 'aaa', 200: 'bbb' }> // "a" | "b" | "100" | "200"

type UnionKeys = GetKeys<{ id: number, a: 1 } | { id: number, b: 2 }> // "a" | "b" | "id"

microsoft / TypeScript