make boolean literal be a literal expression #42154
Conversation
typescript-bot
added
the
For Uncommitted Bug
Kingwl
changed the title
typescript-bot
added
For Backlog Bug
| @@ -1074,8 +1074,12 @@ namespace ts { | |||
| return SyntaxKind.FirstLiteralToken <= kind && kind <= SyntaxKind.LastLiteralToken; | |||
| } | |||
|
|
|||
| export function isBooleanLiteral(node: Node): node is BooleanLiteral { | |||
| return node.kind === SyntaxKind.TrueKeyword || node.kind === SyntaxKind.FalseKeyword; | |||
There was a problem hiding this comment.
I wish we could move TrueKeyword inside the First/LastLiteralToken range, but it would probably not be worth the breaks it would cause.
| readonly kind: SyntaxKind.FalseKeyword; | ||
| readonly text: never |
There was a problem hiding this comment.
I'm not a big fan of this. Maybe it would be better to change isLiteralExpression to type guard to a supertype of LiteralExpression? Presumably callers will want to access text, and should know that it's not defined in some cases.
There was a problem hiding this comment.
I'm also not a fan of this. We use LiteralExpression to mean things that have a possibly differentiating literal value represented as a sequence of unicode characters (i.e., string, number, bigint, RegExp literal). This also disregards null as being a "literal" value. We perhaps could introduce a super-type shared between LiteralExpression and these keyword expressions, but I would not support a change that introduced an unused text property.
|
@weswigham Do you have an idea of how to address either of the problems I mentioned? |
There was a problem hiding this comment.
If there's a place where out terminology is wrong, I think maybe it's more appropriate to call them BooleanKeywords rather than BooleanLiterals (though that name's already taken!), since literals are usually open-ended and these are very much not. Plus, I don't want an UndefinedLiteral or a NullLiteral later. In any case, I'm not sure this is a great idea. I'm going to close this ♥
Fixes #42153