number should be subtype of keyof T[]

[maiermic]

TypeScript Version: 2.1.5

Code

let key: keyof string[]
key = 1 // Type '1' is not assignable to type '"length" | "toString" | "toLocaleString" | "push" | "pop" | "concat" | "join" | "reverse" | "shif...'.

interface Container<T> {
 [index: number]: T
}

let key: keyof Container<string>
key = 1 // Type '1' is not assignable to type 'never'.

Expected behavior:

number should be subtype of keyof string[] and keyof Container<string>

Actual behavior:

number is no subtype of keyof string[] and keyof Container<string>

[mhegazy]

At runtime, any index is really a string. so keyof T is a subtype of string and not string|number. If you are indexing into an array, i would just use number.

[maiermic]

The following example is mentioned in keyof and Lookup Types:

function getProperty<T, K extends keyof T>(obj: T, key: K) {
 return obj[key]; // Inferred type is T[K]
}

It does not work to access elements of T if T is an array:

getProperty(array, 1) // Type '1' is not assignable to type '"length" | "toString" | "toLocaleString" | "push" | "pop" | "concat" | "join" | "reverse" | "shif...'.

You can solve this by overloading:

function getProperty<E>(obj: E[], key: number): E
function getProperty<T, K extends keyof T>(obj: T, key: K): T[K]
function getProperty(obj: any, key: any): any {
 return obj[key]
}

So I just did what you suggested:

If you are indexing into an array, i would just use number.

However, this does not work, if T is a type variable of an interface:

interface Wrapper<T> {
 getProperty<K extends keyof T>(key: K): Wrapper<T[K]>
}

If T is not an array then number should not be allowed as key (which is the case in the example above). However, if T is an array you can not add an overloaded signature like before, because that invalidates the case of the previous sentence (T is not an array). Besides that, you don't know the element type of T.

interface Wrapper<T> {
 // the overload in the next line should only be applied if T is an array
 getProperty(key: number): any // return type is any since you do not know the element type of T
 getProperty<K extends keyof T>(key: K): Wrapper<T[K]>
}

If number would be subtype of keyof T and T is an array E[] then T[number] would return E. If T is not an array then number is not subtype of keyof T.

[maiermic]

Moreover, it seems inconsequent to me that keyof { [key: string]: number } is string and keyof { [key: number]: number } is never.

[LennyLixalot]

We just hit this limitation ourselves. We're filtering some command objects that have their type identified by a numeric ID and were hoping to have them properly typed in our filter method. This is the workaround we have right now, but as you can see it's ugly. We're passing the ID in as a string instead of a number (yuck) and then converting every command's ID to string to compare it, also yuck.

If numbers were supported in keyof as well as strings, this would just work.

interface Commands {
 [id: number]: IncomingCommand;

 20: IncomingCommand & {
 commandTwentySpecificValue: number
 }
}

function on<TId extends keyof Commands>(id: TId, f: (command: Commands[TId]) => void){
 // Calls f for every command that passes through where potentialCommand.id.toString() === id
}

on("20", command => {
 console.log(command.commandTwentySpecificValue);
});

[DanielRosenwasser]

What about adding an overload like this?

function getProperty<T>(obj: { [index: number]: T }, key: number): T

It wouldn't fix all your problems, but it'd work in certain places.

[goloveychuk]

Faced with this when tried to improve immutablejs methods with typesafety.

interface Record<T> {
 setIn<K1 extends keyof T>(k: [K1], v: T[K1]): void;
 setIn<K1 extends keyof T, K2 extends keyof T[K1]>(k: [K1, K2], v: T[K1][K2]): void;
 setIn<K1 extends keyof T, K2 extends keyof T[K1], K3 extends keyof T[K1][K2]>(k: [K1, K2, K3], v: T[K1][K2][K3]): void;
 setIn<K1 extends keyof T, K2 extends keyof T[K1], K3 extends keyof T[K1][K2], K4 extends keyof T[K1][K2][K3]>(k: [K1, K2, K3, K4], v: T[K1][K2][K3][K4]): void;
 setIn<K1 extends keyof T, K2 extends keyof T[K1], K3 extends keyof T[K1][K2], K4 extends keyof T[K1][K2][K3], K5 extends keyof T[K1][K2][K3][K4]>(k: [K1, K2, K3, K4, K5], v: T[K1][K2][K3][K4][K5]): void;
}

This works nicely until T is nested object. When it'd be Array or Map - keyof can't detect keytype of it.

Maybe solution could be ability to explicitly declare keyof. E.g.

type MyArray = { 
 [keyof]: number
}

Also saw you are planning making variadic generics. Will they help solving this problem?

[LennyLixalot]

Why was this closed? Should we take it you never intend to support this feature? Does this count as wont-fix or working-as-intended?

[mhegazy]

The issue was auto-closed since there was no clear action. and has not been touched in more than 14 days.

As noted earlier, number does not exist at runtime, only strings. a solution would be to add a new primitive type numericString that is a subtype of string but is comparable to number, then change all these index signatures to allow for use of numericString and convert number implicitly to numericString. This however seems too complex both from implementation and from usage perspective compared to the value gained by addressing the issue.

[maiermic]

The issue was auto-closed since there was no clear action. and has not been touched in more than 14 days.

Mohamed Hegazy (@mhegazy) Please reopen. In my opinion, this discussion is not done. I guess Vadym Holoveichuk (@goloveychuk) and Lenny Lixalot (@LennyLixalot) do agree. No one reacted to my counter arguments:

• generic type variables of an object

• design discrepancy

They are approved by use cases of Vadym Holoveichuk (@goloveychuk) and Lenny Lixalot (@LennyLixalot). @goloveychuk's use case refers to the current design limitation regarding generic type variables of an object and @LennyLixalot's use case refers to the mentioned design discrepancy. My suggestion would solve both use cases.

The only argument for the current design decision is

At runtime, any index is really a string. so keyof T is a subtype of string and not string|number. If you are indexing into an array, i would just use number.

I still don't get, why at runtime is a design factor in this case.

The 2 in years[2] is coerced into a string by the JavaScript engine through an implicit toString conversion.
See MDN

If at runtime is crucial, indexing into an array using number wouldn't be allowed. That wouldn't be useful and TypeScript allows number as key of arrays. But wait!

number is no subtype of keyof string[]

Wat

number is not keyof Container<T> even though it is explicitly declared as such:

interface Container<T> {
 [index: number]: T
}

Wat

Mohamed Hegazy (@mhegazy) Please elaborate on this. Why should at runtime still be a design factor in this case, but not in others?

[LennyLixalot]

Yes, we agree that something should be done about this, it's overly restrictive and has forced us to make a few sub-par design decisions to maintain strong-typing.

[mhegazy]

This how the feature was implemented originally, and we ran into other issues and had to be restricted to a subtype of string. see more details in #12425.

So unless there is a new proposal on how to mitigate these issues but still support indexing with numbers, not sure reopening this issue adds much.

[maiermic]

Mohamed Hegazy (@mhegazy) where are those other issues documented/mentioned? Do you mean #12314? Are there other issues?

Knowing those issues helps to find a proper solution 🙂