Repository navigation
Narrow on element access of literal - #26424
Merged
Nathan Shively-Sanders (sandersn) merged 7 commits intoAug 15, 2018
Merged
Nathan Shively-Sanders (sandersn) merged 7 commits into
Nathan Shively-Sanders (sandersn) merged 7 commits into
Conversation
This means that, for example, the tuple `[number, string?]` allows its
second element to be narrowed with element access:
```ts
export function f(pair: [number, string?]): string {
return pair[1] ? pair[1] : 'nope';
}
```
Member
Author
|
Webpack breaks with this pattern: // @Filename: declarations.d.ts
declare function mappy(map: { [s: string]: number }): void;
// @Filename: Compilation.js
export class C {
constructor() {
/** @type {{ [assetName: string]: number}} */
this.assets = {};
}
m() {
// Error: '{}' is not assignable to '{ [assetName: string]: number }'
mappy(this.assets)
}
}Note that this is because of our this-property assignment inference; the equivalent Typescript code doesn't treat the initializer of a class' property declaration as a narrowing assignment. Edit: Never mind, this is not narrowing, and it repros on master. I'll fix it separately. |
Nathan Shively-Sanders (sandersn)
requested a review
from Anders Hejlsberg (ahejlsberg)
August 13, 2018 22:21
Member
Author
|
No breaks from Definitely Typed either, so I'm pretty confident that the Breaking Change label on this PR is only theoretical code that we happen to have in our test suite. |
Nathan Shively-Sanders (sandersn)
requested a review
from Ryan Cavanaugh (RyanCavanaugh)
August 14, 2018 22:29
Ryan Cavanaugh (RyanCavanaugh)
approved these changes
Aug 15, 2018
Ryan Cavanaugh (RyanCavanaugh)
deleted the
narrow-on-element-access-of-literal
branch
August 15, 2018 17:39
Nathan Shively-Sanders (sandersn)
added a commit
that referenced
this pull request
Oct 5, 2018
|
Nathan Shively-Sanders (@sandersn) Symbols are still not supported. => Should #23135 be reopened? |
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.
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 means that, for example, the tuple
[number, string?]allows its second element to be narrowed with element access:Or you can narrow on properties that don't work with property access:
This only works for actual literal references, not expressions with literal types, to prevent the binder from making the control flow graph much bigger than it is currently. In other words, this doesn't work:
Performance is not significantly different from today, even on the Compiler, Unions Edition, which is full of very large unions:
Finally, unions with index signatures behave slightly differently:
Which is visible in one baseline change. I'll check the user tests and Definitely Typed, then report back.
Fixes #10530 (and probably a few others that are still open; there are tons of duplicates of this one.)