Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Optimize substitution types #50397
Optimize substitution types #50397
Changes from 4 commits
c09b7dc
a4a9ede
e73d268
f48a923
95ea0ba
aed9659
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this just when someone writes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume so. The check was already there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you mentioned it in person, but remind me again: Why does this need to be
noConstraintType
?AFAIK,
noConstraintTypeshould mostly just be used as a marker to make
getBaseConstraintOfTypereturn
undefined, but a type parameter constrained to
unknownand a type parameter without a constraint are supposed to be functionally identical nowadays. So if this change was required somewhere, I think it implies something is subtly broken. In any case, we should probably make
noConstraintTypean
unknown` variant at some point (since it's still an empty object), even if it's never supposed to actually be used as a type.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The one difference I ran into is in
getConstraintOfDistributiveConditionalType
. It does nothing for type parameters declared without a constraint, but applies a distributive conditional type to a declared type parameter constraint, even if that constraint isunknown
. Changing this would definitely be a breaking change.Making matters worse, for a restrictive type parameter we used to jam in an
unknown
constraint even for a type parameter declared without a constraint--which effectively changed the observed constraint for a distributive conditional type.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ew, icky. Distributive constraints behaving differently for
T
vsT extends unknown
is definitely pretty bad - do we know which direction's behavior is better? Given the direction of this PR, I'm led to think we should adopt the unconstrainedT
behavior for aT extends unknown
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a meaningful break in behavior, right? Previously
type FilterNever<T> = T extends never ? T : never
would have allowedFilterNever<A>
to be assignable toFilterNever<B>
(where A and B are both type parameters), sinceT & never
is justnever
, and eliminated the need to relate the type parameter part, no?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is in the code path for
identityRelation
, so hardly matters. In your particular example the types wouldn't relate anyway because the type parameters aren't identical.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what would technically make it a break, right? Previously this related substitutions only, so
A
subA & never
andB
subB & never
both looked identically likenever
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's true. But they definitely shouldn't be related, so I guess this fixes a bug as well.