Repository navigation
Cannot bracket-index into an object after checking it's existence on that object. #44117
Description
Bug Report
Cannot bracket-index into an object after checking it's existence on that object.
The same failure was reported in #43651, but I couldn't find a separate discussion or a ticket for this.
🔎 Search Terms
- implicitly has an 'any' type
- bracket indexing
🕗 Version & Regression Information
Worked in 4.2.4. Starts to break since 4.3.0-beta
⏯ Playground Link
💻 Code
interface A {}
function foo(a:A) {
if ('abc' in a) {
const z = a;
// Element implicitly has an 'any' type because expression of type '"abc"' can't be used to index type 'A'.
// Property 'abc' does not exist on type 'A'.
return z['abc'];
}
}🙁 Actual behavior
Compiler gives an error that you cannot index into type 'A', since 'abc' does not exist in type 'A'
🙂 Expected behavior
Compiler recognizes the existence check and does not give an error.
Observation
This seems to be caused by the improvement in the control flow analysis/type inference. Before the type of z in the below example was 'never' prior to TS4.3, but now the compiler recognizes z being type A
Question : I have one question though, is it by design that it's allowed to index into never types?
Activity
MartinJohns commentedon May 17, 2021
See #34867.
DanielRosenwasser commentedon May 17, 2021
Yeah but this worked before - Anders Hejlsberg (@ahejlsberg) sounds like we need to at least document this as a breaking change unless we believe it's a regression.
ahejlsberg commentedon May 18, 2021
The current behavior seems right to me, but I'm not sure what caused the change.
ahejlsberg commentedon May 18, 2021
Caused by #38610, which is specifically about not narrowing to
never. As I said above, I think the current behavior is more desirable, but I suppose it is a breaking change. But really, anything relying on the old behavior seems suspicious given that you can indexneverwith anything and not see an error. The issue that #38610 fixes is thatneverisn't a correct reflection of theincheck. The check absolutely could succeed since pretty much anything is assignable to{}.