Microsoft/TypeScript

Misleading EPC error on deferred generic type when assigning any object literal, but empty object is also not assignable

Open

#56.391 aperta il 14 nov 2023

Vedi su GitHub
 (1 commento) (0 reazioni) (0 assegnatari)TypeScript (6726 fork)batch import
BugDomain: check: Excess Property CheckingHelp Wanted

Metriche repository

Star
 (48.455 star)
Metriche merge PR
 (Merge medio 6g 17h) (9 PR mergiate in 30 g)

Descrizione

🔎 Search Terms

N/A (bug report forked from #56388)

🕗 Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play?#code/C4TwDgpgBAylC8UDeAPAXFA5AQwEYGNMBfAKADMBXAO32AEsB7KqMgHgBUoIVgIqATAM6wAfAAoAlMhJQo+JoOBR0yANoBrKHWbtVmFJgC6hjFQoBbXBABORBMjz4MARjsB6N1ACiABQDCXNbWDNYANCwhUNhUIFrm2ADm2ngANtDqECAycgpKIBhIGlo6egbGphZWtvZI7p7yQRC0UKCQgcHWJKRAA

💻 Code

type S = {x: 'abc'}
function f<T extends S>() {
  const x: {[k in T['x']]: number} = {abc: 1} // EPC error, for any imaginable key
  const y: {[k in T['x']]: number} = {} // ...but this is also a (correct!) type error
}

🙁 Actual behavior

EPC diagnostic on any non-empty object literal, but {} is also not assignable.

🙂 Expected behavior

No EPC diagnostic; should just be a straight assignability failure.

Additional information about the issue

Producing an EPC (excess property check) error for any non-empty object literal here is misleading since that ultimately implies {} would be a legal value (it is not). 5.3 exacerbates this because it removes the "X is not assignable to Y" text from EPC diagnostics, which further implies that the value would be legal if assigned indirectly (also not true; the type is generic and might have other properties).

Guida contributor