allow computed properties in destructuring, treat computed properties… #5535
Conversation
… with literal expressions similar to literal named properties
|
|
||
| ({[foo2()]: bar3} = {bar: "bar"}); | ||
| ~~~ | ||
| !!! error TS2353: Object literal may only specify known properties, and 'bar' does not exist in type '{}'. |
There was a problem hiding this comment.
These seem suboptimal.
Maybe we should introduce a rule that if there are dynamically named entities in a contextual type, then we don't perform the strict checking.
There was a problem hiding this comment.
I would disagree with that and would rather be more pessimistic. Requesting opinions of @ahejlsberg, @mhegazy and @RyanCavanaugh.
There was a problem hiding this comment.
Ultimately, I don't really care enough because I don't know who is going to use this.
There was a problem hiding this comment.
I agree with @DanielRosenwasser here. If the contextual type has computed property names it seems strange to restrict the source to only declared properties (which is practically guaranteed to not include the computed property). We should only perform the excess property check when there are no unknowns on the target side.
There was a problem hiding this comment.
sure, will relax the rule
|
👍 |
…ins computed properties
|
this PR should also cover #4653 |
|
@mhegazy can you please check this PR? |
| return declaration.name && isDynamicName(declaration.name); | ||
| } | ||
|
|
||
| export function isDynamicName(name: DeclarationName): boolean { |
There was a problem hiding this comment.
i find the name a bit vague.
|
👍 |
…ringPR allow computed properties in destructuring, treat computed properties…
… with literal expressions similar to literal named properties. Fixes #4917