strictNullChecks mode - variable initial value is ignored in the control flow

[aliai]

TypeScript Version: nightly (2.0.2)

In strictNullChecks mode only:

Code

    interface IFoo {
      foo?: string;
    };

    var a: IFoo = { foo: '' };
    a.foo.split('');  // <-- Error: a.foo is possibly undefined!

Expected behavior:

This is a valid piece of code. a.foo is defined, therefore, a.foo.split is a valid expression.

Actual behavior:

a.foo is concluded as type string | defined, even though it is defined in the initiation phase var a:IFoo = { foo: '' }. tslint/typescript complains that foo is possibly undefined and therefore, cannot access to split method.

the following code runs without problem simply because foo is assigned after a declaration:

    var a: IFoo = {};
    a.foo: '';
    a.foo.split('');

[alitaheri]

{ foo: '' } is assignable to IFoo. so the type of a becomes IFoo. in the second code you're assigning something to a.foo and the control flow analyzer can prove that a.foo has value. I understand what you're asking the type-checker is valid, but it's way too far fetched!

Embrace for By Design or Working as Intended 😅

[aliai]

I don't know if I've managed to explain the problem clearly. I'll elaborate :)

The first code snippet doesn't work and that's the bug I am writing about. a.foo is initialized as a string and not a string|undefined. The linter fails to recognize that there is a initial value for a. And therefore, I cannot call split method on a.foo because it thinks that it is string|undefined.

The code fails on the last line a.foo.split('')

[HerringtonDarkholme]

@alitaheri This snippet might help illustrate the problem.

var a: string | null = 'str'

a.split('123') // no error

a = null

a.split('123') // error

[alitaheri]

@aliai @HerringtonDarkholme I did get the problem. It's just that I thought maybe the cast to IFoo erases the information about foo.

Interestingly, this code doesn't work either:

interface IFoo {
  foo?: string;
};

let a: IFoo;
a = { foo: '' };
a.foo.split('');  // <-- Error: a.foo is possibly undefined!

This sure does look like a bug to me 😅

[danielearwicker]

Naturally this works fine (inferred type of a):

let a = { foo: '' };
a.foo.split('');  // <-- no error

The reason for adding the explicit type annotation is because you are planning to assign to a objects that may or may not have a foo property. Therefore code such as a.foo.split does need to be protected against that possibility. In future maintenance it might move away from its current position and get a line inserted before it that changes a. The compiler is being helpful based on what you've told it.

If you don't want the help, don't ask for it! :) (just remove the type annotation from a).

[aliai]

@danielearwicker yes for the example I provided it may look silly to annotate the type :) But, this is just a simplified example to show the bug, not the necessity. The use case of this can vary of course:

    interface IUser {
      name: string;
      permissions?: {
        adminRights?: {
            moreInDepthFileld: any;
            thatIWouldLikeToHaveIntellisenseFor: any;
        };
        canPublishPost: boolean;
        canLeaveComments: boolean;
      };
      otherThingsIMightWantForMyObject?: ISomething;
    };

    var user: IUser = { name: 'foo', permissions: {} };
    user.permissions.canPublishPost = ...; // <-- Error

This is not the code I encountered this problem with since it is out of topic here. But it is a close example to the real case. The point being, the compiler doesn't take the initialization phase of the variable into account to not infer object|undefined type in strictNullCheck mode.

[mhegazy]

We only narrow unions. the type of a is not, it is an IFoo. so a is not narrowed. so perhaps we need to consider property declarations as if they were assignments, i.e. treat it as:

var a: IFoo = {};
a.foo = "";
``