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
interfaceFoo<T>{bar<PextendsT>(payload: P): number;// without the extends we actually get a compiler error // bar(payload: T): number;}typePayloadA={valueA: number};constfoo_a: Foo<PayloadA>={bar: (val)=>val.valueA};typePayloadB={valueB: string};letfoo_b: Foo<PayloadB>={bar: (val)=>val.valueB.length};constpayload_a={valueA: 42}satisfiesPayloadAconstpayload_b={valueB: 'test'}satisfiesPayloadBfoo_a.bar(payload_a);// OK - validfoo_a.bar(payload_b);// OK - does not compilefoo_b.bar(payload_b);// OK - validfoo_b.bar(payload_a);// OK - does not compilefoo_b=foo_a;// ERROR - does compile BUT should NOTfoo_b.bar(payload_b)// this will throw at runtime because the above assignment
🙁 Actual behavior
The assignment foo_b = foo_a compiles without errors even though it should not, because Foo and Foo are not compatible (because their functions Foo['bar'] and Foo['bar'] each expect different parameters)
🙂 Expected behavior
The assignment foo_b = foo_a should give a compiler error as their signatures do not match.
Error message should be e.g:
TS2322: Type 'Foo<PayloadA>' is not assignable to type 'Foo<PayloadB>'. Property 'valueB' is missing in type 'PayloadA' but required in type 'PayloadB'
Note
Interestingly we would get the expected behaviour if we used the bar(payload: T): number; instead of bar<P extends T>(payload: P): number;
The text was updated successfully, but these errors were encountered:
Thank you @RyanCavanaugh 🙏 for the quick response and the "variance annotation" tip.
Happy to have the confirmation the described issue is indeed a bug and not somehow feature.
I spent like 20min to look for a duplicate - would never have found the duplicates with the keywords I was using. 😅
Since the duplicates have so radically different wording I hope that this issue still helps others who encounter this bug. Therefore I'd not close this - plz go ahead to close though in case that is standard procedure.
Just for the mention: this also a duplicate of / related to #48070
Looking forward to #48092 getting fixed.
Bug Report
🔎 Search Terms
extends T
suppresses failing type check🕗 Version & Regression Information
5.1
,5.1 nightly
but also1.8
,2.9
and3.9
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
The assignment
foo_b = foo_a
compiles without errors even though it should not, because Foo and Foo are not compatible (because their functions Foo['bar'] and Foo['bar'] each expect different parameters)🙂 Expected behavior
The assignment
foo_b = foo_a
should give a compiler error as their signatures do not match.Error message should be e.g:
Note
Interestingly we would get the expected behaviour if we used the
bar(payload: T): number;
instead ofbar<P extends T>(payload: P): number;
The text was updated successfully, but these errors were encountered: