Skip to content

Setters not accounted for by strictNullChecks & strictPropertyInitialization #24937

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tbillington opened this issue Jun 13, 2018 · 3 comments
Closed
Labels
Duplicate An existing issue was already created

Comments

@tbillington
Copy link

tbillington commented Jun 13, 2018

TypeScript Version: 2.9.2 & 3.0.0-dev.20180609

Search Terms:
setter

Code

When enabling the strictNullChecks and strictPropertyInitialization tsconfig options tsc produces an error when it shouldn't. It looks like the rule implementation of the aforementioned strict flags might not account for setters? Easily verifiable in the typescript repl too, once enabling the flags.

class Foo {
  private _x: number;
  public set x(nx: number) {
    this._x = nx;
  }
  constructor() {
    this.x = 1;
  }
}

tsc: Property '_x' has no initializer and is not definitely assigned in the constructor.

Expected behavior:
No errors.

Actual behavior:
tsc emits Property '_x' has no initializer and is not definitely assigned in the constructor. error.

Playground Link:
http://www.typescriptlang.org/play/#src=class%20Foo%20%7B%0D%0A%20%20%20%20private%20_x%3A%20number%3B%0D%0A%20%20%20%20public%20set%20x(nx%3A%20number)%20%7B%0D%0A%20%20%20%20%20%20%20%20this._x%20%3D%20nx%3B%0D%0A%20%20%20%20%7D%0D%0A%20%20%20%20constructor()%20%7B%0D%0A%20%20%20%20%20%20%20%20this.x%20%3D%201%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A

Related Issues:

@RyanCavanaugh
Copy link
Member

Same root cause as #21132 - setter bodies and function bodies are equally not control-flow-expanded

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Jun 13, 2018
@tbillington
Copy link
Author

Ah interesting. Is this case also a design limitation? I saw from the chain that #20166 was the accepted workaround, would it be the same with this?

@RyanCavanaugh
Copy link
Member

Yes and yes, respectively

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

2 participants