Narrow by property assignment in an object literal#22006
Closed
Narrow by property assignment in an object literal#22006
Conversation
Not sure why, so the code is currently scratched up with investigation.
1. Requires its own FlowFlag because isMatchingReference assumes that it's operating only on references or variable declarations, not initializers. 2. Has a bunch of ugly plumbing in the binder's bindAssignmentTargetFlow; probably it could be simplified. 3. Doesn't add or check control flow nodes recursively, so only top-level property initialisers narrow.
They are accessed via element access, which doesn't participate in control flow for performance reasons.
Member
Author
|
@RyanCavanaugh I think you were interested in this. |
This was referenced Feb 20, 2018
Member
|
Just because it's non-obvious if it works, can we add a test with a binding pattern, ie: // @strict: true
type A = {
x?: string[]
y?: number[]
z?: {
ka?: boolean
ki?: boolean
}
extra?: string
0?: string
'two words'?: string
}
const y = [1, 2, 3]
const wat = { extra: "life" }
let {x, y, z, extra, 0: zero, ["two words"]: words}: A = {
x: [],
y,
z: {
ka: false
},
...wat,
0: 'hi',
'two words': 'ho'
}
x.push('hi')
y.push(4)
let b = z.ka
b = z.ki // error, object is possibly undefined
extra.length // error, reference doesn't match the spread
zero.length
words.length |
Collaborator
|
Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it. |
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
This PR narrows the type of variables that (1) have a type annotation and (2) are initialized with an object literal:
This works recursively, and for shorthand property assignments:
But not for spread assignments — it's too complicated to track reference in the control flow graph — or string-literal/number-literal/computed properties — they are accessed via element access, which doesn't participate in control flow.
Note that FlowInitializer looks very similar to FlowAssignment. I tried re-using the existing structures, but the code size to constantly decide between the two uses was actually quite a bit bigger. Handling FlowInitializer is still very similar to FlowAssignment, but mostly simpler.
Fixes #20219