`keyof T`和`Extract有什么区别 <keyof T, string> `使用扩展泛型时？

Question

Let's say I have an interface that defines valid values for a set of data:

interface Foo {
  bar: boolean;
}

And I want a class to be able to expose that data with a method. I'm finding that it works fine if I use keyof T to define the keys:

abstract class Getter<T> {
  private data: T;

  get<K extends keyof T>(key: K): T[K] {
    return this.data[key];
  }

  abstract use(): void;
}

class ExtendedGetter<T extends Foo> extends Getter<T> {
  use() {
    this.get('bar'); // OK
  }
}

However, restricting the keys to only accept strings with Extract<keyof T, string> causes an error:

abstract class Getter<T> {
  private data: T;

  get<K extends Extract<keyof T, string>>(key: K): T[K] {
    return this.data[key];
  }

  abstract use(): void;
}

class ExtendedGetter<T extends Foo> extends Getter<T> {
  use() {
    this.get('bar'); // ERROR
  }          ~~~~~
}

Argument of type '"bar"' is not assignable to parameter of type 'Extract<keyof T, string>'. ts(2345)

It's also worth noting that, in the second scenario, no error is thrown if Foo is used directly instead of using an extended generic:

class ExtendedGetter extends Getter<Foo> { ... }

Why does this happen?

What is the difference between Extract<keyof T, string> and keyof T that causes the error?

Answer 1

It looks like this behavior is considered to be a bug (see microsoft/TypeScript#24560 ) but I don't see anything indicating it will be fixed in the near future.

But I would tend to lump this into the category of the compiler being unable to assign values to unresolved conditional types . If you have a conditional type like T extends U ? X : Y T extends U ? X : Y and either T or U are unresolved generic types or dependent on unresolved generic types, then the compiler doesn't do much analysis to verify if some value is assignable to it; it mostly just rejects the assignment:

function unresolved<T extends string>() {
  const x: [T] extends [string] ? number : number = 1; // error!
  const y: string extends T ? number : number = 1; // error!  
}

In that case, even though both conditional types pretty much must evaluate to number , the compiler cannot tell that it's safe to assign 1 to variables of those types, at least as of TypeScript 3.6. I see a pull request which might improve this, and possibly it would address your code, but I'm just speculating and I don't know when or if it will make it into the language.

Suffice it to say that Extract<keyof T, string> when T is an unresolved generic is likely to be hard for the compiler to reason about (since the Extract utility type is implemented as a conditional type). Note that once T is resolved to a concrete type like, Foo , then Extract<keyof T, string> is evaluated by the compiler to the concrete type "bar" and there is no problem, as you saw.

---

So, workarounds. One thing you can do, as you noted, is to just use keyof T instead of Extract<keyof T, string> . The type keyof T is known to be assignable from "bar" , despite being generic... the compiler is able to do some reasoning about unresolved generic types; it's just much worse at doing so when the type is conditional. If that works for you, great. But if you want to use Extract<keyof T, string> ...

I would use a type assertion . Type assertions are useful when you know something about the type of a value that the compiler doesn't know. In this case, you are sure that "bar" will be assignable to Extract<keyof T, string> , since "bar" is assignable to both string and keyof T . Face it, you're smarter than the compiler... and type assertions are a good way for you to brag about your superior intelligence:

class ExtendedGetter<T extends Foo> extends Getter<T> {
  use() {
    this.get("bar" as Extract<keyof T, string>); // I'm smarter than the compiler 🤓
  }
}

Type assertions should be used with caution, of course, because if you're wrong about your assertion and lie to the compiler then you're likely to have some unpleasant surprises at runtime. But in this case you can be pretty sure that the assertion is always valid.

---

Okay, hope that helps. Good luck!

Link to code