Proposal: Follow program flow in constructor when strictPropertyInitialization = true

[SetTrend]

Search Terms

constructor strictPropertyInitialization flow

Suggestion

TypeScript should follow unconditional function calls in constructor when checking for strict property initialization.

Use Cases

It is a common pattern to be able to reset objects after construction and, thus, to transfer object initialization to a separate routine:

class C
{
  private p: number;

  public constructor() { Initialize() }

  public Initialize() { p = 0; }
}

Currently, TypeScript doesn't consider functions being unconditionally called from within a constructor function when checking for strict property initialization. The above code yields a compiler error.

I propose TypeScript to be able to analyse code flow and recognize property initialization that's performed in functions unconditionally called by the constructor function.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[DanielRosenwasser]

I've heard C# is looking into this so it's worth discussing why we can't do the same.

[ahejlsberg]

Beyond the complexity of doing inter-procedural control flow analysis, an issue here is that every method in JavaScript is virtual, so we really have no idea where a call to this.initialize() goes (a subclass may override it).

[SetTrend]

I see.

Yet, even in that case, wouldn't it be possible for the derived class to check whether it overrides a function that's called by a base class constructor and go through that path for validation?

Perhaps, in a first iteration, it would suffice to just check for functions immediately called by a constructor - not following the full execution path.

[SetTrend]

I just stumbled over a similar issue, where the base class is abstract and generic:

export default abstract class A<T>
{
  protected _state: T;
}

... results in:

TS2564: Property '_state' has no initializer and is not definitely assigned in the constructor.

You may call this a design flaw as a constructor like:

protected constructor(state: T)
{
  super();
  this._state = state;
}

... may solve the problem. Though, basically, it would be plain correct to omit this redundant constructor.

This error should not occur in an abstract class. It should, however, occur in a non-abstract derived class if all base class constructors and the constructor of the first non-abstract derived class don't set the protected field.

[1valdis]

I just ran into that and I was surprised that method call wouldn't be considered an initialization. Seems like I will have to have a bit of duplicated code.
Edit: managed to workaround by putting ! after property name. Will do for now, but it probably would look better without that.

[beauxq]

This is not only for the false positive pointed out by the author.

This could also prevent a false negative on a null pointer exception (Property is used before being assigned. ts(2565)) that TypeScript is not currently catching.
See: #41446

[beauxq]

Beyond the complexity of doing inter-procedural control flow analysis

Here is an example with both the false positive and the false negative in the same example:

class A {}

class B {
    public foo() {}
}

class C {
    private a: A;  // false positive - `a` is definitely assigned in the constructor
    private b: B;
    constructor() {
        const x = 3;
        this.reset(x);
        this.b = new B();
    }

    private reset(y: number) {
        console.log(y);
        this.a = new A();
        console.log(this.a);
        this.b.foo();  // false negative - `b` used before being assigned
    }
}

Note that both problems (the false negative and the false positive) go away if you pretend that the code looks like this:

class A {}

class B {
    public foo() {}
}

class C {
    private a: A;  // false positive - `a` is definitely assigned in the constructor
    private b: B;
    constructor() {
        const x = 3;
        this.reset(x);
    ((y: number) => {  // copy parameters from the method to here
        // exact copy of the function body
        console.log(y);
        this.a = new A();
        console.log(this.a);
        this.b.foo();  // false negative - `b` used before being assigned
    })(x);  // copy the arguments from the function call to here
        this.b = new B();
    }

    private reset(y: number) {
        console.log(y);
        this.a = new A();
        console.log(this.a);
        this.b.foo();  // false negative - `b` used before being assigned
    }
}

Maybe Typescript could pretend that the code looks like that just for error checking.
For reporting the errors, it would just have to translate line numbers. (That's why I used the weird indentation.)

[fetis]

Without that feature, the usage of strictPropertyInitialization is questionable for me. We've just enabled it in a quite large project and we had to move code from our private initialization methods back to the constructor because TS wasn't able to properly recognize initialization. This made code less readable, which was not my intention at all.

[paul-marechal]

Same over here, I was surprised to see that strictPropertyInitialization checked all branches of the constructor to make sure that the assignment happens, but didn't bother checking function calls. Putting aside complex recursive functions, something simple should work no?