Void type narrowing stops working in callbacks

[blakeembrey]

Seems like this would have been reported, but I had trouble finding a duplicate issue. Feel free to close if one does exist.

TypeScript Version:

nightly (1.9.0-dev.20160217)

Code

let foo: string | void
let cbr: (cb: (err: Error) => any) => any

if (foo) {
  cbr(function () {
    foo.substr(0, 10)
  })
}

Expected behavior: No error

Actual behavior:

index.ts(6,9): error TS2339: Property 'substr' does not exist on type 'string | void'.

Edit: Only visible on nightly - notice that in nightly foo.substr within the if (foo) is valid, but not within the callback function which is also inside if (foo).

[tinganho]

Related to #8353 and #7770.

Statically there is nothing telling the compiler that the callback is executed immediately. Thus foo can be void inside the callback.

let foo: string | void
let cbr: (cb: (err: Error) => any) => any

if (foo) {
  cbr(function () { // compiler doesn't know when the callback is executed.
    foo.substr(0, 10)
  })
}
foo = undefined

[malibuzios]

I'm not sure if it's related to #8353, it seems closer to #8472.

They're somewhat like two sides of the same thing:

• Suggestion: control flow type analysis could account for reassignments through a closure #8353 is about accounting for assignments done (or that may be done) during the execution of a function in the analysis of the caller context.

let x: number | string = "hi";

x; // 'x' is analyzed as 'string'
func();
x; // 'x' is analyzed as 'number'

function func() {
   x = 1;
}

• Global variables in local functions are not control flow analysed #8472 is about accounting for the global state before a particular call in the analysis of the called function.

let x: number | string = "hi";

// 'x' is analyzed as 'string' for execution of this particular call,
// so this may compile:
func();

function func() {
   // However, in general there is no way to know whether the type of 'x' would be
   // 'number' or 'string' here for an arbitrary caller context, so it technically 
   // may still error during compilation, unless perhaps more complex analysis is done:
   return x.charCodeAt(0); 
}

[blakeembrey]

Thanks for the issues, they are all almost the same issues, but the solutions are probably much different. I understand the other issues stated are a bit more complicated - one requires understanding the call locations and another is around mutating variables outside the scope.

I understand that foo could be re-assigned, but in this case it's easy to analyse that because there's no future assignment to foo and it only got into the callback because it was truthy to start with. Just imagine that block is all wrapped in a closure, for example.

Anyway, if it sounds similar enough I'm happy for it to be closed - as long as the issue is being tracked somewhere 😄

[mhegazy]

this is a duplicate of #7662. you can see more discussion in #7719 (comment)

[blakeembrey]

Actually, @mhegazy, I'd like to re-open this issue. I don't think it's entirely correct. For example, if it's a const, you can't re-assign the variable so even in a function it should stay narrowed.

[blakeembrey]

All the referenced issues mention specifically var or let, but if you do something like:

const x: number | number[] = []

function cb () {
  x.push(1)
}

It should work. The const can not be re-assigned to another type.

[mhegazy]

Const should work with latest in master.

[blakeembrey]

Thanks. Is there a particular option to make it work? I just checked out master and am stilling getting:

index.ts(4,5): error TS2339: Property 'push' does not exist on type 'string | string[]'.

[mhegazy]

Sorry about that, should have been more specific. it only narrows in function expressions and lambdas.. so this should work:

const x: number | number[] = []

var cb = function () {
    x.push(1)
}

now that i think about it, i do not see why this should not work for function declarations as well.

[mhegazy]

created #8976 to track that.

[blakeembrey]

Thanks @mhegazy