Remove notion of predicates as types, move predicates back to signatures #6744
Conversation
…rty/get type guards.
…an anything else.
|
Ping. |
| @@ -7092,6 +7082,7 @@ namespace ts { | |||
| case SyntaxKind.Identifier: | |||
| case SyntaxKind.PropertyAccessExpression: | |||
| case SyntaxKind.QualifiedName: | |||
| // TODO (drosen): Why a qualified name? | |||
There was a problem hiding this comment.
It may not be needed - I believe it was just for completeness, since EntityName (which is what the function on the following line takes) is Identifier | QualifiedName - provided I'm remembering that right.
It may very well be that the grammar prohibits a QualifiedName from being passed to this check.
|
Ping. |
|
👍 |
|
LGTM, except I'll probably move changing of error spans for accessor to another PR. This is definitely useful but brings to much noise in tests into this PR |
| if (source.kind !== target.kind) { | ||
| if (reportErrors) { | ||
| errorReporter(Diagnostics.A_this_based_type_guard_is_not_compatible_with_a_parameter_based_type_guard); | ||
| errorReporter(Diagnostics.Type_predicate_0_is_not_assignable_to_1, typePredicateToString(source), typePredicateToString(target)); |
There was a problem hiding this comment.
not specific to this PR, but error messages refer to this sometimes as "type guards" and others as "type predicate"
There was a problem hiding this comment.
Good point I'll file an issue
|
+1 for Vlads comment. |
|
otherwise looks good 👍 |
|
👍 |
Remove notion of predicates as types, move predicates back to signatures
Fixes #6311.
This is an alternative approach to #6328.
Offline discussions have determined that there was not enough review around the idea of type predicates on accessors and properties. This moves them back to signatures, keeps
this-based predicates, and continues to infer from type predicates.@mhegazy