3.5.1 (regression): "string cannot be used to index T" where T is Record<string, any>

[lll000111]

This is new as of 3.5.1, there was no error in 3.4.5.

Error message:

TS2536: Type 'string' cannot be used to index type 'T'

Obviously wrong, since T is defined as Record<string, any>.

function isString (thing: unknown): thing is string {
    return typeof thing === 'string';
}

function clone<T extends Record<string, any>>(obj: T): T {
    const objectClone = {} as T;

    for (const prop of Reflect.ownKeys(obj).filter(isString)) {
        objectClone[prop] = obj[prop];
    }

    return objectClone;
}

Playground Link — It will not show an error until the Playground uses the new TS 3.5.x

[felix9]

Here's a similar case I ran into:

interface Bag {
  [key: string]: number;
}

function put<T extends Bag>(a: T, k: string, v: number): void {
  a[k] = v;
}

Compiling that produces this:

$ tsc test.ts
test.ts:6:3 - error TS2536: Type 'string' cannot be used to index type 'T'.

6   a[k] = v;
    ~~~~

Found 1 error.

[RyanCavanaugh]

This is the intended behavior but I need to write several pages of documentation for "How do index signatures in generic constraints work [if at all]"

[felix9]

Confusingly, this will compile without error (though --noImplicitAny will complain):

interface Bag {
  [key: number]: boolean;
}
function put<T extends Bag>(a: T) {
  a["x"] = "y";
}

[ahejlsberg]

This is an effect of #30769 and a known breaking change. We previously allowed crazy stuff like this with no errors:

function foo<T extends Record<string, any>>(obj: T) {
    obj["s"] = 123;
    obj["n"] = "hello";
}

let z = { n: 1, s: "abc" };
foo(z);
foo([1, 2, 3]);
foo(new Error("wat"));

In general, the constraint Record<string, XXX> doesn't actually ensure that an argument has a string index signature, it merely ensures that the properties of the argument are assignable to type XXX. So, in the example above you could effectively pass any object and the function could write to any property without any checks.

In 3.5 we enforce that you can only write to an index signature element when we know that the object in question has an index signature. So, you need a small change to the clone function:

function clone<T extends Record<string, any>>(obj: T): T {
    const objectClone = {} as Record<string, any>;

    for (const prop of Reflect.ownKeys(obj).filter(isString)) {
        objectClone[prop] = obj[prop];
    }

    return objectClone as T;
}

With this change we now know that objectClone has a string index signature.

[felix9]

I'm still a little confused by that explanation. Given this dubious bit of code, in both --strict and non-strict mode, the only complaint is the baggish["z"] = 3 line. I'm not sure why that line in particular gets to be the fatal error, and the only fatal error?

interface Bag {
  [k: string]: number;
}

function put1(bag: Bag) {
  bag["z"] = 3;
}

function put2<T extends Bag>(baggish: T) {
  baggish["z"] = 3;
}

const bag: Bag = {};
put1(bag);
put2(bag);

type Point = {x: number};
const point = {x: 3};
put1(point);
put2(point);

[lll000111]

In general, the constraint Record<string, XXX> doesn't actually ensure that an argument has a string index signature, it merely ensures that the properties of the argument are assignable to type XXX.

I don't accept this "explanation".

Why is there even a place for the key type in Record<keyType, valueType if it has no meaning???

So, in the example above you could effectively pass any object and the function could write to any property without any checks.

That is the whole point!!! That's why the type is Record, string,...>! Note that "string" as type for the key and not some limited union.

[lll000111]

Also: Why would it EVER complain — in Javascript! — if I use a string as index in an object? By using Record I already told TS that it is meant to be a generic map object. The explanation does not make sense.

In general, coming from (the more strict!) Flow, all those many errors I now have in TypeScript when I iterate over my objects (using Object.keys) that "there is no index signature" are really, really... strange.

Alternatively, please document how to document generic (key-prop/value) objects when what I do is iterate over the keys. Without "any". Thus far I read the documentation to mean that Record<string, any> was meant to do exactly that?

[patroza]

Not sure if this helps the case: const typedKeysOf = <T>(obj: T) => Object.keys(obj) as Array<keyof T>

[lll000111]

@patroza If that helps, and maybe in general anyway (I have not thought about wider implications), what if Object.keys and Reflect.ownKeys were declared that way (TS standard lib), instead of as Array<string | number | symbol> ?

As an experiment I changed the definition in lib.es2015.refelect.d.ts

from (PropertyKey is string | number | symbol)

function ownKeys(target: object): PropertyKey[];

to

function ownKeys<T extends object>(target: T): Array<keyof T>;

and everything is PERFECT now! I had to remove the .filter(isString) because that widens the type to string again, but that filter is not needed in this context.

So maybe the underlying TS-lib definition can be looked and any maybe changed?