Open jcalz opened 5 months ago
I think it is just a bug in the control flow analysis. The current graph for prevPrevFoo
in prevPrevFoo?.bar
can be seen here
@RyanCavanaugh so this is not considered a bug, but a missing feature, right?
Eh, bug is probably more accurate
π Search Terms
assignment narrowing, optional chaining, narrowing to never,
π Version & Regression Information
β― Playground Link
Playground link
π» Code
π Actual behavior
prevPrevFoo
is apparently narrowed tonull
via assignment narrowing, soprevPrevFoo?.bar
gives an error thatnever
doesn't have abar
property. ButprevPrevFoo
is assigned within the loop, so it seems strange that the narrowing persists in that scope.π Expected behavior
No error,
prevPrevFoo
should be consideredFoo | null
inside the loop.Additional information about the issue
Comes from this SO question. Not sure what's going on here, but it seems quite dependent on the nesting and order of operations. Most things I did to try to reduce it further made the error disappear.
Note that this is not a case of #9998, there's no closure to speak of. And of course we can work around this by opting out of assignment narrowing via
let prevPrevFoo = null as Foo | null;
. I don't think this is a big deal, but it would be nice to know the cause of this and whether it's a bug, design limitation, or somehow working as intended (and if so, why).