TypeScript: 3.5.1 (regression): "string cannot be used to index T" where T is Record

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?

What about this?

target can be indexed while source cannot?

function deepMerge<T1 extends Record<string, any>, T2 extends Record<string, any>>(
  source: T1,
  target: T2
): T1 & T2 {
  Object.keys(target).forEach(key => {
    if (source[key] == null) {
      source[key] = target[key];
    } else if (typeof source[key] === 'object') {
      if (typeof target[key] === 'object') {
        deepMerge(source[key], target[key]);
      } else {
        source[key] = target[key];
      }
    } else {
      source[key] = target[key];
    }
  });

  return source as any;
}

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]”

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.

I’m trying to understand this change, but having trouble with the current explanations. In particular, it’s unclear why the change should apply specifically to a generic type T extends Bag and not to a regular non-generic Bag. For example, the “previously allowed crazy stuff” (from https://github.com/microsoft/TypeScript/issues/31661#issuecomment-497138929) is still allowed if you change function foo<T extends Record<string, any>>(obj: T) to function foo(obj: Record<string, any>). It’s equally crazy in that context, no?

@ahejlsberg, you tried to address the distinction at https://github.com/microsoft/TypeScript/issues/31661#issuecomment-497474815, but it seems like that explanation has a similar problem. Your example shows that the new behavior prevents put2 from adding an extra (unknown) property and returning it as the original type (a Point). However, the following code compiles without any errors:

function put3(point: Point): Point {
  point["z"] = 3;
  return point;
}

const p3: Point = put3({ x: 3 });

So, again, why should the generic code be restricted more than the non-generic equivalent? I’ve been trying to unpack the following for a clue:

In effect, constraining a type parameter to Bag merely checks that T is assignable to Bag, but it doesn’t imply that T is a Bag.

But again it’s not clear how this is different from non-generic parameters – if I pass a value to a non-generic parameter of type Bag, isn’t it also just an assignability check? Isn’t ~everything just an assignability check in a structural type system?

I think it will help a lot to see some specific examples of real-world errors this is intended to fix (if you only have time for a quick response, this would be the most helpful). So far, the compelling error cases I’ve seen (the “previously allowed crazy stuff” mentioned above) seem to be a result of the special behavior of Record<string, any> being assignable to any type.

Are there many errors you’re seeing that don’t involve that? If not, I would put forth an alternate proposal: for generic constraints, only ignore index signatures equivalent to Record<string, any>, and go back to the old behavior for all others.

This would hopefully make the language simpler and more consistent, and save @RyanCavanaugh from having to write several pages of documentation 😄 (would love to hear your take on this, Ryan, and/or Anders).

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);

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

@felix9 The distinction becomes evident when you consider both input (parameter) and output (function result) positions. Imagine that put1 and put2 returned the object passed to them:

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

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

const p1: Point = put1({ x: 3 });  // Error
const p2: Point = put2({ x: 3 });

Following a call to put1 you now have a Bag and Bag is not assignable to Point. And because the argument has been promoted to Bag, the function is permitted to write to any property.

However, following a call to put2 you still have a Point. So, the type checker needs to restrict the function to only allow writing to properties that are known to exist in T. In other words, it should only allow assignments to T[K] where K is a keyof T or something constrained to keyof T. In effect, constraining a type parameter to Bag merely checks that T is assignable to Bag, but it doesn’t imply that T is a Bag.

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.

As I am reading the discussion above, it seems to me that {x: 3} should not be assignable to Bag type, because it does not have any indexer property to satisfy the Bag interface.

That would one way to do it. However, it is very common to initialize map-like objects using object literals, and for an object literal we know the exact set of properties from which to compute an implicit index signature. So we permit the assignment for types originating in object literals.

When I think about the clone function mentioned earlier in the discussion, I would rewrite it as follows

I’d write it like this:

function clone<T extends object>(obj: T): T {
  const objectClone = {} as T;
  const ownKeys = Reflect.ownKeys(obj) as (keyof T)[];
  for (const prop of ownKeys) {
    objectClone[prop] = obj[prop];
  }
  return objectClone;
}

No need to use index signatures anywhere. And, to recap, for the reason Reflect.ownKeys is not typed as (keyof T)[], see https://github.com/microsoft/TypeScript/pull/12253#issuecomment-263132208.

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";
}

How about this one:

export const deepMerge = <T extends object = object, U extends object = object>(a: T, b: U) => {
    let result = Object.assign(a, b)
    for (const key in a) {
        if (!a[key] || (b.hasOwnProperty(key) && typeof b[(key as unknown) as keyof U] !== 'object')) continue

        Object.assign(result, {
            [key]: Object.assign(a[key], b[(key as unknown) as keyof U])
        })
    }

    return result
}

(1)

In effect, constraining a type parameter to Bag merely checks that T is assignable to Bag, but it doesn’t imply that T is a Bag.

Here is the part I find highly confusing:

• when I write class Foo extends Bag, it means Foo is a Bag
• when I write function put<Foo extends Bag>, it DOES NOT mean that Foo is a Bag

As I am reading the discussion above, it seems to me that {x: 3} should not be assignable to Bag type, because it does not have any indexer property to satisfy the Bag interface.

If that was the case, the the example put2({x: 3}) above would trigger a compilation error.

(2) Now going back to foo example:

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

IMO, the code above is valid in the sense that it’s ok to assign to s and n properties, because Record<string, any> does allow that. What I don’t consider as correct is to call foo with such obj value that does not have indexer property mapping arbitrary key to any value.

I think a more correct definition of foo would say that the Record type has only keys of T, something along the following lines:

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

Such code is triggering the following error for me: Element implicitly has an 'any' type because type 'Record<keyof T, any>' has no index signature.ts(7017), which is a good sign that we are doing something wrong here. Personally, I would expect a different error - Property 's' does not exist on type 'T'.

Because foo wants to work with s and n properties, I think it should list them in the Record template arguments.

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

That way the compiler can verify:

• inside foo that we are accessing only those obj properties that exist on T
• code calling foo provides obj value that allows s and n properties

(3) When I think about the clone function mentioned earlier in the discussion, I would rewrite it as follows:

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

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

  return objectClone;
}

This seems to work with TypeScript v3.5, although I am surprised that Reflect.ownKeys is returning string[] instead of (keyof T)[].

Thoughts?

@patroza For the reason Object.keys isn’t typed as (keyof T)[], see https://github.com/microsoft/TypeScript/pull/12253#issuecomment-263132208.