Contextually type binding initializers#7298
Conversation
Previously they were not contextually typed, which meant that lambdas got completely incorrect types, and that types that rely on contextual typing, like tuples and string literal types, did not work correctly.
|
I forgot to re-run tests after merging from master and one of the new tests failed. I'll fix it and update the PR. |
|
The baselines were missing Mohamed's improved serialisation of binding elements that doesn't print the initialiser as part of the type. |
| const name = declaration.propertyName || declaration.name; | ||
| if (isVariableLike(parentDeclaration) && | ||
| parentDeclaration.type && | ||
| (name.kind === SyntaxKind.Identifier || name.kind == SyntaxKind.StringLiteral)) { |
There was a problem hiding this comment.
You don't have any tests right now for when the name is a string literal.
There was a problem hiding this comment.
In which case, wouldn't those properties be computed? What about the following cases?
This should have no errors:
interface Foo {
prop: (x: string) => number;
}
function f({ ["prop"]: local = v => +v }: Foo) {
}This should have an error:
interface Foo {
prop: (x: string) => number;
}
function g({ ["prop"]: local = v => v }: Foo) {
}There was a problem hiding this comment.
This JSON-like syntax is allowed, which is the StringLiteral case, I believe:
function f( { "prop": local = v => +v }: Foo) {
}The code you give is a ComputedPropertyName, I believe. I'll test all four.
Also, I used == instead of === by mistake. I'm not sure how the linter missed that.
There was a problem hiding this comment.
Yup, looks like ComputedPropertyName was missing. Thanks for the help finding and fixing the oversight.
With tests and associated baseline updates
|
👍 |
…tializers Contextually type binding initializers
Fixes #5762
Previously they were not contextually typed, which meant that lambdas got completely incorrect types, and that types that rely on contextual typing, like tuples and string literal types, did not work correctly.