-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ts] Add support for expr satisfies Type
expressions
#14211
Conversation
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/53224/ |
expr satisfies Type
expressions
this.next(); // "as" or "satisfies" | ||
if (this.match(tt._const)) { | ||
if (isSatisfies) { | ||
this.raise( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't have to specialize tt._const
after tt._satisfies
: tsParseType
should throw when const
is seen.
This feature won't make its way into TypeScript 4.6 - it's still being iterated on, so if we can figure out the issues with it, 4.7 will be the earliest it can land. |
Thank you! |
The TS pull request has been merged, I'll rebase this. |
ffc98e5
to
ec54229
Compare
Depending on the 7.19 timing, we might need to postpone this to 7.20. |
ec54229
to
036704f
Compare
036704f
to
110b104
Compare
110b104
to
28c8a0b
Compare
// name, since const isn't allowed as a type name. So in this instance we | ||
// get to pretend we're the type checker. | ||
if (typeReference.typeParameters) { | ||
this.raise(TSErrors.CannotFindName, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CannotFindName
seems to be used only here.
typeAnnotation, | ||
}); | ||
} | ||
export { tsSatisfiesExpression as tSSatisfiesExpression }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be a bug.😕
edited: No, just a little ugly.🙃
"Type expression" sounds like something that operates on types only whereas in |
I disagree. An adjective does not describe an operand but a property of the thing itself. In math, we don't call the addition symbol a "number expression". It operates on numbers, it itself is not a number. This is a "type expression" because it expresses a type to either:
Makes sense to me. |
The exposed names are TSAsExpression and TSSatisfiesExpression; TSTypeExpression is just an internal variable name. |
@ngregory-rbi You have a point, but in TypeScript there is this dichotomy between values and types. And when it's needed to specify one of these contexts, this kind of wording is used. E.g. "type operators" here. On the other hand, I just noticed that the TS team strictly avoids using the word "expression" for type-only things, which makes
Can't help myself, excuse me :) , but what about "dog food" then? Is it a dog? |
Fair enough.
Not sure how your conclusion connects to the preceding statement.
Fair point as well. Touché. Regardless of anything, wording may be a tangential subject to this PR. |
The preceding statement was against applying the wording "type expression" to upd: an example where "type expression" has the meaning I expected. @nicolo-ribaudo There are your questions about naming in the first post here, so I thought they were still relevant. |
Oh thanks, I forgot about it 🙃 Re-reading my original post, I don't like TSBinaryExpression because it feels like it should be an expression between two TS things, but this one is between a JS value and a type. For Babel 8, TSTypeExpression might be fine, however I'm open to alternative suggestions! |
@thorn0 I meant more the two segments here:
If the TS team "strictly avoids" using the word "expression", why does it make Babel using the term a "better choice than [you] thought"? Would you not want to keep the same wording as the TS team? |
@ngregory-rbi They avoid it for type-only things. |
Please merge this as soon as possible :) |
Release tomorrow! |
microsoft/TypeScript#46827 is in the TypeScript 4.6 iteration plan: I'm opening this PR so that we are ready in case it gets merged before Babel 7.17.0. However, I'm marking this PR as a draft because that one is still marked as a draft (@DanielRosenwasser, do you think that there is any chance that that PR will be actually included in 4.6, even if you already released a beta without it?).
I'm not convinced by the new AST node I introduced for
expr satisfies Type
expressions. It feels like it should be the same node asTSAsExpression
, similarly to howin
andinstanceof
both areBinaryExpression
s. Ideally, something like this:however, that would be a breaking change. I also considered just adding
operator
toTSAsExpression
, but{ type: "TSAsExpression", operator: "satisfies" }
looks wrong.Maybe we could go for the breaking change in Babel 8, and for now provide a
TSBinaryExpression
alias in@babel/types
?TSBinaryExpression
orTSTypeExpression
? The new node would not cover<Type> expr
, because it needs to visit its childrens in a different order (type before expression).