Object is possibly null inside a closure defined within a const constraint

[benallfree]

Search: Object is possibly null, narrowed type, type constraint, closure

Code

const foo: string | null = 'bar'
if (foo) {
    function baz() {
        console.log(foo.length)  // Object is possibly 'null'
    }
}

Expected behavior:

Compiles

Actual behavior:

const foo: string | null
Object is possibly 'null'

Playground Link:

Playground

Related Issues:

#12113, #33319, #9998

Discussion:

By design, type narrowings are reset inside closures. This makes sense, but there is one case where better assumptions can be made: when the closure is defined inside a type constraint block AND the type narrowing is based on a const value. Even if called from async, the closure is still referencing a const and was created after a suitable type constraint occurred.

Thoughts?

[benallfree]

Actually now I think this issue should be closed because the behavior is correct. Consider this:

let foo: string | null = 'bar'
const delegate: { baz: ()=>void }: { baz: ()=>{} }
if (foo) {
    function baz() {
        console.log(foo.length)  // Object is possibly 'null'
    }
    delegate.baz = baz
}
foo = null
delegate.baz() // runtime failure

edit April 24: this is a bad example, foo = null is not possible because foo is const

[johnsoncodehk]

In principle, TypeScript can check whether the function is allocated. (Not sure should I open a feature request.)

if (foo) {
    function baz() {
        console.log(foo.length)  // Object is 'string' | 'null'
    }
    delegate.baz = baz
}

if (foo) {
    function baz() {
        console.log(foo.length)  // Object is 'string'
    }
    // no assign for baz
}

Or design a keyword to prevent the function allocated.

if (foo) {
    static function baz() {
        console.log(foo.length)  // Object is 'string'
    }
    delegate.baz = baz // error: function can't be allocated because function is static
}

[benallfree]

Hi @johnsoncodehk I think Typescript behaves correctly already. Consider this:

if(foo) {
   function baz() {
      console.log(foo.length)  // Object is possibly null
    }
    setTimeout(baz,100)
}

Since there is no way to guarantee that foo is defined at the time baz() is called in all cases, Typescript is correct to catch that it might be null even though foo was defined when baz() was created.

[johnsoncodehk]

@benallfree in this case baz is assign to a function param, so foo is possibly null, but if baz do not have any assign in the closure, but only have synchronize calling, foo will not be null.

But I just found a other case so we can't do that:

if(foo) {
  baz(); // foo is not null here
  foo = null
  baz(); // foo is null here but no type error
  function baz() {
     console.log(foo.length)
   }
}

[benallfree]

@johnsoncodehk Right. Then do you agree also that this issue should be closed?

[johnsoncodehk]

Yes, I do. :)

[benallfree]

Closing per discussion.

[benallfree]

Sorry, reopening, I think I might be confusing myself. @johnsoncodehk this issue is about a const constraint, so the value of foo should never change. I think this issue may be valid after all.

const foo: string|null = 'bar' // I think this maybe should be type narrowed to 'string'
if(foo) { // TS should know that `foo.length` is always valid here
}

So maybe the real question is why const foo:string|null='bar' isn't type narrowed to foo:string?

[johnsoncodehk]

This issue seem to have 2 problems now.

In you comment, it seem not a closure type narrowing problem, but is a problem of type picking priority in function.

const foo: string | null = 'bar'
function baz() {
  console.log(foo.length) // Object is possibly 'null'
}

In this case function preference to string | null not 'bar' even foo is const, I believe this is design to select the most initial definition.

---

(remove this part because updated before comment)