TS2454 and var hoisting

[spencerhakim]

TypeScript Version: 2.6.1

Code
I have some code vaguely similar to the following, which takes advantage of var hoisting; strictNullChecks is enabled:

if (input.a) {
    var a = doSomething(input.a); // returns a string
}
if (input.b) {
    var b = doSomethingElse(input.b); // returns a string
}
if (input.c) {
    var c = doAThirdThing(input.c); // returns a string
}

let options = {
    a, // error TS2454: Variable 'a' is used before being assigned
    b, // error TS2454: Variable 'b' is used before being assigned
    c // error TS2454: Variable 'c' is used before being assigned
};

Expected behavior:
a, b, and c should probably have implicit types of string | undefined, and no errors should be thrown.

Actual behavior:
a, b, and c have implicit types of string, and TS2454 is thrown.

---

For the moment, explicitly setting the types with var a: string | undefined = ... is a workaround, but I'm not a fan of how verbose that is, and I don't believe it should be needed.

[mhegazy]

The intention is not clear here. did you mean to set them to a string but forgot an else branch, or meant them to be string | undefined...

the compiler will use an explicit type annotation if one is present. if not, it will infer the type from the intialzier, and in this case it was inferred to be a string. Control flow really does not change the type, it narrows the possible types it can have.

my recommendation here is to add an explicit type annotation.

[spencerhakim]

I intended for them to be string | undefined, since those are the possible types they'd have given that control flow. It would seem to me that any var declaration inside a conditional block should be typed as [normally inferred type] | undefined, since that would be the result of hoisting. Consider this:

let a = input.a ?
    doSomething(input.a) :
    undefined;

This is functionally equivalent to my original code, but the type is correctly inferred as string | undefined. I understand why the type is correctly inferred in this scenario and not the one in my original comment, but my argument is that the current type inference behavior for my original code isn't entirely correct.

[isao]

I think it'd be better to declare var a, b, c; at the top of the function. Most linters will require it, and I'm fine with TypeScript requiring it as well.

[spencerhakim]

@isao That would entirely defeat the purpose of using var instead of let, it's fairly desirable to want to keep variable declaration and definition in the same line. Plus, TypeScript is supposed to be a superset of JavaScript, with all valid JS code also being valid TS code; adopting arbitrary linter rules as hard language requirements would break that compatibility. Despite var semantics getting a lot of crap over the years, it's nice being able to take advantage of its oddities.

[isao]

@spencerhakim I understand, and I mean no offense. My comment is kind of like, Patient: "Doc it hurts when I do X", Doctor: "Don't do X". The validity of my argument depends entirely on whether or not you think X is ok or dangerous. It's a Crockford-esque position.

OTOH "TS2454: Variable 'c' is used before being assigned" is a linting kind of error. I think it's a common pitfall, and doesn't doing var a, b, c; at the top of the function solve your issue?

[spencerhakim]

@isao No offense taken. Doing var a, b, c; at the top removes the errors, but only because their types are inferred as any, which is even worse. And, again, I'm now declaring variables on one line and defining them on another, and losing the benefit of using var over let.

My issue here isn't that I don't know how to get rid of the errors, but that the errors are only occurring because the TypeScript compiler is inferring the type incorrectly in this scenario. This discussion should be focusing on that.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.