New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inequivalent intersection types are treated as equivalent #42204
Comments
I'm not blocked by this issue and from my point of view it seems low-priority. |
I believe the same issue applies regardless of intersection types - for example, if you just have two otherwise identical types with re-ordered signatures. I'd say this is either a design limitation (we might want to fix it if there was a clear non-breaky technique to do this right) or just working as intended. |
Thanks for taking a look.
I can confirm that the behavior is the same with call signatures. The playground shows the same behavior if Z1 and Z2 are defined as follows: interface Z1 {
(thing: string): string
(thing: unknown): number
}
interface Z2 {
(thing: unknown): number
(thing: string): string
}
It's a soundness hole. I haven't been bitten by it, but I can see it causing real bugs. A change that would be backwards-compatible for code that isn't buggy would be to consider order in checkTypeRelatedTo in cases where order matters. The "cases where order matters" might just be intersections and interfaces where domains overlap but codomains do not. I couldn't concoct a version of this bug for mapped types. |
I don't find these type definitions to be coherent, so don't really think we can make true statements about them.
|
If backwards-compat weren't a concern, I suppose a good solution would be to forbid I do suspect Sounds like this is working as designed–shall I close the issue? |
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
Bug Report
Inequivalent intersection types are treated as equivalent.
This issue seems to arise for intersections of function types with overlapping domains. In these cases, order matters when it comes to calculating return types based on arguments, but does not seem to matter for assignability.
🔎 Search Terms
intersection, intersection type, assignability, equivalence
🕗 Version & Regression Information
4.1.3
Nightly–I think 4.2.0-dev.20210104
4.0.5
3.9.7
3.8.3
3.75
3.6.2
3.5.1
3.333
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
z1 (of intersection type Z1) and z2 (of intersection type Z2) have different behavior: the return types of z1("") and z2("") are distinct. Yet z1 and z2 are interassignable and TS thinks Z1 and Z2 extend each other.
🙂 Expected behavior
In the code example, I'd expect either t1 and t2 to have the same type or for Z1 and Z2 to be inequivalent (not inter-assignable, not mutually-extending).
The text was updated successfully, but these errors were encountered: