Proposal: Follow program flow in constructor when strictPropertyInitialization = true

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.

[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.

[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.