Consistent widening in access expressions#31802
Conversation
|
@typescript-bot run dt |
|
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 1aed26a. You can monitor the build here. It should now contribute to this PR's status checks. |
|
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 1aed26a. You can monitor the build here. It should now contribute to this PR's status checks. |
| } | ||
|
|
||
| function isMethodAccessForCall(node: Node) { | ||
| while (node.parent.kind === SyntaxKind.ParenthesizedExpression) { |
There was a problem hiding this comment.
This should probably? also skip both kinds of casts.
There was a problem hiding this comment.
No, if there is an intervening type assertion then that specifies the type and widening isn't relevant.
sandersn
left a comment
There was a problem hiding this comment.
I think this is a good fix, but I'm worried that we need a bigger rethinking of widening at some point. Right now the rules are getting to be a complex patchwork that is hard to explain.
|
@typescript-bot test this |
|
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 1aed26a. You can monitor the build here. It should now contribute to this PR's status checks. |
|
@typescript-bot test this |
|
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 69706bd. You can monitor the build here. It should now contribute to this PR's status checks. |
|
@typescript-bot test this |
|
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 4856768. You can monitor the build here. It should now contribute to this PR's status checks. |
With this PR, in a property access
obj.xor element accessobj["x"]we widenobjwhen the property or element access is (a) the target of an assignment, or (b) a method access in a call expression (i.e. the this of the call). These are the situations in which we are mutating (or possibly mutating) the object and therefore should widen its type.Previously we'd always widen
objin a property access and never widenobjin an element access, which was inconsistent.Fixes #31728.
Fixes #31762.