Reintroduce definitelyAssignableRelation and use with conditional types #39577
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@typescript-bot test this |
|
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 854229a. You can monitor the build here. |
|
Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 854229a. You can monitor the build here. |
|
Heya @ahejlsberg, I've started to run the perf test suite on this PR at 854229a. You can monitor the build here. Update: The results are in! |
|
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 854229a. You can monitor the build here. |
|
@ahejlsberg Here they are:Comparison Report - master..39577
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Tests are clean (failures are all preexisting conditions). Except for |
weswigham
reviewed
Jul 13, 2020
src/compiler/checker.ts
Outdated
| if (source.flags & TypeFlags.Index) { | ||
| if (result = isRelatedTo(targetType, (<IndexType>source).type, /*reportErrors*/ false)) { | ||
| return result; | ||
| if (relation !== definitelyAssignableRelation) { |
There was a problem hiding this comment.
Why does the definite assignment relation skip over relating keyof S and keyof T?
There was a problem hiding this comment.
If we have two keyof types, then S and T are distinct generic types. Since they're not the same type and generic types have no constraints under this relationship, seems there's no point in further exploration. Also, if I change to include this check we get circularity errors in the circularlySimplifyingConditionalTypesNoCrash.ts test plus error baseline changes in two other similar tests.
There was a problem hiding this comment.
What if we're relating keyof S to keyof substitute(S, S & T)?
There was a problem hiding this comment.
Or even keyof S to keyof Q[T] where the value of Q[T] is only ever S (eg, because every property in a concrete Q is of type S)?
A lot of type relationships are subsets or supersets of others (i.e. identitical ≤ subtype of ≤ assignable to ≤ comparable to). It's not clear to me that that's the case with the definitelyAssignable relationship - maybe it's a subset of assignable to? Either way, I experimented with a layered cache check that leveraged that a few years back, but saw no real difference on the codebase. You might see it in a stress test like material-ui though. |
It's a subset of the assignable-to relation in the sense that when assignable-to is false then definitely-assignable-to is also false. It's possible we might save time in our determination of whether to defer conditional types by first checking for assignable-to and, only when that's true, then checking for definitely-assignable-to. But of course were then doing even more work in the true case. |
|
Latest commit is an experiment to see the effects of checking assignable-to before definitely-assignable-to. Note that there are baseline changes because the more aggressive constraint explorations of assignable-to cause circularity errors. |
|
@typescript-bot perf test this |
|
Heya @ahejlsberg, I've started to run the perf test suite on this PR at 289ba80. You can monitor the build here. Update: The results are in! |
|
@ahejlsberg Here they are:Comparison Report - master..39577
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This doesn't feel like a "Pay 1% perf penalty to fix it" bug given that this is our first report in 9 versions of shipping it. Are there other positive impacts in favor of it? |
I don't necessarily mean requesting that work - I mean just checking whether that work has already been done before in other caches before starting any work. Check whether something is |
|
No positive effect from performance experiment, so reverting that. |
# Conflicts: # src/compiler/checker.ts
|
@DanielRosenwasser I did a few experiments with your idea, specifically, if we have cached a true for definitely-assignable-to then assignable-to is also true, and if we have cached a false for assignable-to then definitely-assignable-to is also false. Unfortunately, it doesn't seem to have any effect. @RyanCavanaugh Yes, a 2.5% performance definitely doesn't seem worth it for this rather obscure corner case. But, material-ui is an outlier and generally I wouldn't expect any measurable difference. In terms of other positive impacts of the change, it's simpler because we can get rid of the restrictive instantiation and its associated cache. But probably not a big deal. |
typescript-bot
added
the
For Uncommitted Bug
# Conflicts: # src/compiler/checker.ts
|
@ahejlsberg is it worth it to keep this open; would you want to merge it for 4.2 after the 4.1 RC is out? |
|
@DanielRosenwasser Let's discuss in a design meeting before we make a final call. |
|
My vote is early 4.2 (i.e. merge on Monday) if we decide to take it. |
|
@typescript-bot perf test this |
|
Heya @ahejlsberg, I've started to run the perf test suite on this PR at d2e3a35. You can monitor the build here. Update: The results are in! |
|
@ahejlsberg Here they are:Comparison Report - master..39577
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The 10/30/2020 notes still don't show whether we decided to take this PR. @DanielRosenwasser or @ahejlsberg do either of you remember? Do we need to discuss this again? |
|
I'm going to close this PR for now to reduce clutter. We can re-open it if there's demand for it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #39364.