Uh oh!
There was an error while loading. Please reload this page.
Type guard by deep property - #38839
Conversation
12ab497 to
d221e6bCompareShuiRuTian
commented
Jun 18, 2020
thanks to @KoyamaSohei, I use his test code. |
ShuiRuTian
commented
Jun 28, 2020
Friendly Ping @andrewbranch ~ |
andrewbranch
commented
Jun 29, 2020
Thanks for putting this together @ShuiRuTian! I looked through a bunch of the changed test baselines last week, and my suspicion is that this change is going to be too big for 4.0 now that we’ve released the beta (we try not to add any big features or breaking changes during this period). I’m on DefinitelyTyped duty this week, but will try to give this a more careful review next week and discuss with the team. Just wanted to set expectations that even if all the changes look perfect, we may decide it needs to wait until 4.1. Thanks again! |
ShuiRuTian
commented
Jun 30, 2020
Oh, glad to know the plan, just at your own pace! @andrewbranch |
f3e4ba4 to
9ac7412Compare
andrewbranch
left a comment
There was a problem hiding this comment.
The baseline changes definitely look like desirable changes to me. I’m not very familiar with control flow in the checker so I’d want @ahejlsberg and/or @weswigham to review the implementation. Thanks!
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
andrewbranch
commented
Jul 2, 2020
@typescript-bot test this |
Heya @andrewbranch, I've started to run the parallelized community code test suite on this PR at 9ac7412. You can monitor the build here. |
Heya @andrewbranch, I've started to run the extended test suite on this PR at 9ac7412. You can monitor the build here. |
Heya @andrewbranch, I've started to run the perf test suite on this PR at 9ac7412. You can monitor the build here. Update: The results are in! |
typescript-bot
commented
Jul 2, 2020
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
typescript-bot
commented
Jul 2, 2020
@andrewbranch Here they are:Comparison Report - master..38839
System
Hosts
Scenarios
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
bba4520 to
840cb01CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
DanielRosenwasser
commented
Jul 13, 2020
Let's take this up at the next design meeting. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| return isTypeArrayDiscriminant(propertyTypeArray, isRootHasUndefinedOrNull); | ||
| } | ||
| function narrowTypeByDiscriminantNew(type: Type, access: AccessExpression, narrowTypeCb: (t: Type) => Type): Type { |
There was a problem hiding this comment.
narrowTypeCb used to just be called narrowType, and I think that's what it's still called elsewhere.
| functionnarrowTypeByDiscriminantNew(type: Type,access: AccessExpression,narrowTypeCb: (t: Type)=>Type): Type{ | |
| functionnarrowTypeByDiscriminantNew(type: Type,access: AccessExpression,narrowType: (t: Type)=>Type): Type{ |
There was a problem hiding this comment.
I add postfix because there is another function really named narrowType, I confuse them for some times.
I have no idea, is it a bad choice in fact?
| if (propType.flags & TypeFlags.Union) { | ||
| (propType as UnionType).types.forEach(t => subtypes.push(t)); | ||
| } | ||
| else subtypes.push(propType); |
There was a problem hiding this comment.
| if(propType.flags&TypeFlags.Union){ | |
| (propTypeasUnionType).types.forEach(t=>subtypes.push(t)); | |
| } | |
| elsesubtypes.push(propType); | |
| forEachType(propType,t=>subtypes.push(t)); |
There was a problem hiding this comment.
Suprising, I find that this is not equal. forEach would not always run callback on each item.
forEachType(propType, t => {subtypes.push(t)});
Only when the callback not return value, they are totally same. Maybe this is not a bug, just a little annoying.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ShuiRuTian
commented
Jul 14, 2020
@DanielRosenwasser Thanks for taking this up and a lot of suggestions which help code much more readable |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
typescript-bot
commented
Oct 7, 2021
The TypeScript team hasn't accepted the linked issue #32399. If you can get it accepted, this PR will have a better chance of being reviewed. |
andrewbranch
commented
Oct 7, 2021
🤨 @typescript-bot go home, you’re drunk |
73be1db to
4ae2a07CompareShuiRuTian
commented
Oct 19, 2021
Now that I am a member of MS, follow my orders, robot! @typescript-bot test this |
e0c5a62 to
8be3a1dCompare
This comment has been minimized.
This comment has been minimized.
0392be2 to
40521d7CompareAuh, we need some more PR to do things correctly. Here are the list and reasons:
And there are some bugs I have no idea how to fix, so I use Also, this PR #42556 brings a good optimize, but it only works for direct constituent. I will consider how to bring it back in the following PR. |
Andarist
commented
Jan 23, 2022
@ShuiRuTian@andrewbranch what's the current status of this PR - is there anything I could do to help here (including implementation or investigating some uncovered/undecided stuff)? |
ShuiRuTian
commented
Jan 24, 2022
@Andarist Andrew tried bringing the PR to some releases, but obviously, the effort failed. Personally, I think it might be even a good thing. It proves the team does not rush to a new feature, but make decisions carefully. PS: Chinese New Year is coming, Happy Tiger Year! |
…truthiness add tests update tests fix remove useless code fix test reference clean code clean code one level alias could be narrowed by deep property fix fix bootstrap
9370627 to
233d341CompareShuiRuTian
commented
Jan 25, 2022
The conflict is resolved. Ready to receive feedback at any time :) |
weswigham
left a comment
There was a problem hiding this comment.
Looks like a merge went a bit wrong? Buncha things seem off that prior reviews would have flagged.
| return candidate; | ||
| } | ||
| } | ||
| // if (clauseStart < clauseEnd && type.flags & TypeFlags.Union && getKeyPropertyName(type as UnionType) === getAccessedPropertyName(access)) { |
| } | ||
| } | ||
| } | ||
| // if ((operator === SyntaxKind.EqualsEqualsEqualsToken || operator === SyntaxKind.ExclamationEqualsEqualsToken) && type.flags & TypeFlags.Union) { |
| break; | ||
| default: | ||
| throw Debug.assertNever(node.operator); | ||
| throw new Error("never"); |
There was a problem hiding this comment.
You shouldn't need to make this change. assertNever is here to ensure all possible cases for node.operator are handled.
| return isErrorType(type) ? errorType : createNewTargetExpressionType(type); | ||
| default: | ||
| Debug.assertNever(node.keywordToken); | ||
| throw new Error("never"); |
There was a problem hiding this comment.
Likewise, Debug.assertNever is ansuring node.keywordToken is exhaustively handled - it shouldn't be removed.
| return; | ||
| } | ||
| // @ts-ignore |
There was a problem hiding this comment.
Definitely can't have a //@ts-ignore for any reason in our codebase. There's always some other way to handle whatever's going on.
| const platform: string = _os.platform(); | ||
| const useCaseSensitiveFileNames = isFileSystemCaseSensitive(); | ||
| const realpathSync = _fs.realpathSync.native ?? _fs.realpathSync; | ||
| const realpathSync = _fs.realpathSync.native; |
There was a problem hiding this comment.
Bad merge? Pretty sure the fallback should still be here.
| break; | ||
| default: | ||
| Debug.assertNever(projectService.serverMode); | ||
| throw new Error("never"); |
There was a problem hiding this comment.
Again, should still be assertNever.
| break; | ||
| default: | ||
| Debug.assertNever(this.projectService.serverMode); | ||
| throw new Error("never"); |
There was a problem hiding this comment.
Again, should still be assertNever.
| // filter handles case when 'projects' is undefined | ||
| projects = filter(projects, p => p.languageServiceEnabled && !p.isOrphan()); | ||
| if (!ignoreNoProjectError && (!projects || !projects.length) && !symLinkedProjects) { | ||
| // @ts-ignore |
| break; | ||
| default: | ||
| Debug.assertNever(state.specialSearchKind); | ||
| throw new Error("never"); |
There was a problem hiding this comment.
Again, should still be assertNever.
ShuiRuTian
commented
Mar 5, 2022
@weswigham enumFooKind{one,two,three,}interfaceFoo{kind: FooKind}functionFooFunc(tmp: Foo){switch(tmp.kind){caseFooKind.one:
break;caseFooKind.two:
break;caseFooKind.three:
break;default:
tmp;// what should here be? should it be `Foo` or `never`?}}In the new PR, I narrow Now, let's say we have code |
RyanCavanaugh
commented
Jun 20, 2022
From the looks of it, this feature is unfortunately much more complex to implement than we had anticipated, and we don't think that the cost/benefit ratio is good in this case. As much as we want to support this pattern, the implications of these changes feel too far-reaching (even if they're necessary to actually support the scenario). We'll leave the original issue open in case later on down the line a simpler method of approach becomes available, but we aren't comfortable with introducing this much complexity in a critical codepath right now. All that said, putting this much time into the investigation is something we appreciate a ton. Thank you for all the effort you've put in into authoring this. |
jcalz
commented
Sep 21, 2022
This would also maybe have addressed #42384? |
Fixes#32399
Fixes#18758
support
ifclause,switchclause and??to narrow type by nest property forTypeof,Truthiness,DiscriminantThere some limitations described here #38839 (comment)
And we need to do more things described here as following PR #38839 (comment)