[] is regard wrong as never[] when strictNullChecks is true

[k8w]

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

[mhegazy]

An empty array without a type annotation can not be inferred to have any type. If --strictNullChecks is off, it is inferred to be undefined[] and then widened to any[]. if --strictNullChecks, undefined is not in the domain of any type, so it is not inferred. so you are left with a never[].

Add a type annotation or an intializer to avoid getting a never[].

[DanielRosenwasser]

Why can't we use control-flow analysis so that users get the "smart" behavior that they get with --noImplicitAny?

[mhegazy]

Why can't we use control-flow analysis so that users get the "smart" behavior that they get with --noImplicitAny?

cause noImplicitAny is set to false in the config file above. if it is set to true, control flow analysis gets the type of output as any[] since obj is any. you will get an error on obj however, since it is implicitly any.

[DanielRosenwasser]

What I mean is: can we change the behavior so that users get similar behavior as if they did enable noImplicitAny when they enable strictNullChecks?

[mhegazy]

That was discussed in #12359. and the conclusion was not to do that.

[DanielRosenwasser]

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 noImplicitAny alone is that it was a breaking change - but if we infer never[] under strictNullChecks, I don't see how this would possibly be a breaking change for any reasonable cases.

[mhegazy]

The two bugs listed were the reason. Being a breaking change and causing perf regressions.