Repository navigation
[] is regard wrong as never[] when strictNullChecks is true #13140
Description
TypeScript Version: 2.1.1 / nightly (2.2.0-dev.201xxxxx)
2.1.4
Code
test.ts
function test(obj): any[]{
let output = [];
for(let k in obj){
output.push(obj[k]);
}
return output;
}tsconfig.json
{
"compilerOptions": {
"module": "commonjs",
"target": "es6",
"strictNullChecks": true,
"noImplicitAny": false,
"sourceMap": false
}
}Expected behavior:
Compile successfully.
Actual behavior:
test.ts(4,21): error TS2345: Argument of type 'any' is not assignable to parameter of type 'never'.
Maybe output should be treated as any[] ?
It would compile successfully if strictNullChecks: false
Activity
mhegazy commentedon Dec 26, 2016
An empty array without a type annotation can not be inferred to have any type. If
--strictNullChecksis off, it is inferred to beundefined[]and then widened toany[]. if--strictNullChecks,undefinedis not in the domain of any type, so it is not inferred. so you are left with anever[].Add a type annotation or an intializer to avoid getting a
never[].DanielRosenwasser commentedon Dec 26, 2016
Why can't we use control-flow analysis so that users get the "smart" behavior that they get with
--noImplicitAny?mhegazy commentedon Dec 26, 2016
cause
noImplicitAnyis set tofalsein the config file above. if it is set to true, control flow analysis gets the type ofoutputasany[]sinceobjisany. you will get an error onobjhowever, since it is implicitlyany.DanielRosenwasser commentedon Dec 27, 2016
What I mean is: can we change the behavior so that users get similar behavior as if they did enable
noImplicitAnywhen they enablestrictNullChecks?mhegazy commentedon Dec 28, 2016
That was discussed in #12359. and the conclusion was not to do that.
DanielRosenwasser commentedon Dec 28, 2016
Since I don't see it recorded in the meeting notes, do you recall the justification?
My understanding is that the reason we didn't do it outside of
noImplicitAnyalone is that it was a breaking change - but if we infernever[]understrictNullChecks, I don't see how this would possibly be a breaking change for any reasonable cases.mhegazy commentedon Dec 28, 2016
The two bugs listed were the reason. Being a breaking change and causing perf regressions.