Property lookups on arguments to type parameters constrained by string index signatures can violate other constraints because undefined is included for optional properties

[aweebit]

🔎 Search Terms

index signature, indexed types, mapped types, lookup types, optional properties, generic constraints

🕗 Version & Regression Information

• It's only been possible to assign optional properties to string index signature since version 4.2 (see Make optional properties assignable to string index signatures #41921)
• The bug has existed ever since

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/C4TwDgpgBAkgznArhAPAFShAHsCA7AEzigG8oBtLALijmACcBLPAcwF0a9EBbAIwnoBuKAF8AfFAC8UAHI8BjAMbpyAawggA9gDMoaNmMEBYAFChIs+U2UzMOfEShc+AidJnGz4aAA0psBGQUMgBDAH5OHn56UUMgA

💻 Code

type Issue<T extends { [x: string]: number; }> = Numeric<T[keyof T]>;
type Numeric<N extends number> = N;
type X = Issue<{ a?: 0 }>;

🙁 Actual behavior

During the evaluation of X, T[keyof T] becomes { a?: 0 }['a'], which in turn is evaluated as 0 | undefined because a is an optional property. Therefore, the argument passed to Numeric is 0 | undefined. This type doesn't satisfy the extends number constraint and therefore should not be permitted. However, the compiler doesn't report any errors.

🙂 Expected behavior

An error is reported on line 1, saying that the N extends number constraint might be violated.

Additional information about the issue

The same happens with the mapped type { [x in string]: number; }.

The problem only exists for string index signatures: for both { [x: number]: number; } and { [x: symbol]: number; }, there are errors reported.

#41921 might've been a mistake. Perhaps a new tsconfig option could be introduced that would revert the change so that the rule for assignment of optional properties to string index signatures is more strict and consistent to how number / symbol index signatures are handled again? With "exactOptionalPropertyTypes": true at least, the original issue #41418 should not cause trouble anymore. Actually, I think that the introduction of exactOptionalPropertyTypes is exactly how the issue should have been solved back then. Unfortunately, the setting was only introduced later (in version 4.4).