You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the example below CType should have been resolved to number.
Actual behavior:
CType was resolved to number | boolean | undefined.
Interestingly when I take the optional marker ? out of the r parameter in the signature of either SomeAbstractClass.foo or SomeAbstractClass.bar, then CType is inferred properly even though such a change seems like it would play absolutely no role in the inference of CType.
This is definitely a strange one, but it's an easy fix.
Here's what's happening: During inference we obtain base signatures (using getBaseSignature) in which we substitute constraints for type parameters declared in the signatures. This is a fine thing to do for an inference source signature, but not so much for an inference target signature because it may, in rare cases, create unintended new inference targets. That's what's happening in the examples above. Specifically, in an inference target, the this[K] type in the set method becomes BaseType<T1, T2>[keyof BaseType<T1, T2>] which becomes a union of the function types of the methods in the class. We then proceed to infer from each method type in the source to each method type in the target, and we get meaningless results.
The simple fix is to use the erased signature in the target. In an erased signature we substitute any for type parameters declared in the signature. That causes this[K] to become any, meaning we're not creating unintended new inferences targets.
TypeScript Version: 3.8.3
Search Terms:
wrong inferred generic type infer operator optional argument signature interference
Expected behavior:
In the example below
CType
should have been resolved tonumber
.Actual behavior:
CType
was resolved tonumber | boolean | undefined
.Interestingly when I take the optional marker
?
out of ther
parameter in the signature of eitherSomeAbstractClass.foo
orSomeAbstractClass.bar
, thenCType
is inferred properly even though such a change seems like it would play absolutely no role in the inference ofCType
.Related Issues:
Code
Output
Compiler Options
Playground Link: Provided
The text was updated successfully, but these errors were encountered: