-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Add assignability rules for when the target is a conditional type #27932
Conversation
7652906
to
f590103
Compare
When you write:
By instantiated are you referring to the instantiation of the infer parameters? Would it be possible to write a small example that shows the difference between the proposed behaviour, and the behaviour if you only consider the uninstantiated true constraint (as opposed to the intersection)? I have a hard time translating the rules into concrete examples, so it would be greatly appreciated! |
Does this address the unsoundness in #26945? |
This experiment is pretty old, so I'm going to close it to reduce the number of open PRs. |
Inspired by looking into #27014
Fixes #26933
Steals from #27589
This adds assignability rules for relating types when the target is a conditional type. We only check for conditional type target assignability when:
never
Given these circumstances, a type is assignable to the conditional in question if
true
(yet hasinfer
types, preventing simplification) and it is assignable to the intersection of the instantiated constraint of thetrue
branch and the uninstantiated constraint (this allows for "independent" infer types to not interfere with true branch assignability, whilst still preserving the assignment-blocking part of the existential-like behavior of theinfer
types).