Skip to content
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

Option for strictPropertyInitialization to check even potentially undefined properties #26015

Closed
marcomura opened this issue Jul 27, 2018 · 7 comments
Labels
Add a Flag Any problem can be solved by flags, except for the problem of having too many flags Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds

Comments

@marcomura
Copy link

marcomura commented Jul 27, 2018

Opening new bug since the previous got closed without any explanation.

Why strictPropertyInitialization should require strictNullChecks?

class C {
    foo: number;
    bar = "hello";
    baz: boolean;
    //  ~~~
    //  Error! Property 'baz' has no initializer and is not assigned directly in the constructor.
    constructor() {
        this.foo = 42;
    }
}

Without stringNullChecks, I can solve the error explicitly assigning undefined to baz.

@ajafff
Copy link
Contributor

ajafff commented Jul 27, 2018

IIRC control flow analysis only happens when strictNullChecks is enabled.

In addition strictPropertyInitialization only checks properties that cannot contain undefined. As you already noted, without strictNullChecks everything can contain undefined.

@j-oliveras
Copy link
Contributor

Duplicate of #24716 and #23659.

@ghost ghost added the Duplicate An existing issue was already created label Jul 27, 2018
@ghost
Copy link

ghost commented Jul 27, 2018

Given:

class C {
    x: number | undefined;
    y: number;
}

There will be an error at y, but not at x. But without --strictNullChecks, the fact that x can be undefined isn't tracked -- instead everything is assumed to potentially be undefined. So --strictPropertyInitialization would have nothing to do because undefined is a legal value of every property.

@marcomura
Copy link
Author

"This PR implements a new --strictPropertyInitialization compiler option to guard against uninitialized properties in class instances".
I would prefer this to mean "if you want your field to be undefined, you have to explicitely assign undefined".

E.g., with --strictPropertyInitialization but without --strictNullChecks:

Given:

class C {
x: number | undefined;
y: number;
}

there should be an error in both.

Given:

class C {
x: number | undefined = undefined;
y: number = undefined;
}

no errors.

This is the compiler option I'm looking for, and this is the behavior I thought --strictPropertyInitialization had.

@marcomura
Copy link
Author

Should I open a proposal for a new compiler option?

@ghost ghost changed the title Option 'strictPropertyInitialization' cannot be specified without specifying option 'strictNullChecks' Option for strictPropertyInitialization to check even potentially undefined properties Jul 27, 2018
@ghost ghost added Suggestion An idea for TypeScript and removed Duplicate An existing issue was already created labels Jul 27, 2018
@ghost
Copy link

ghost commented Jul 27, 2018

Let's just make that this issue.

@RyanCavanaugh RyanCavanaugh added Add a Flag Any problem can be solved by flags, except for the problem of having too many flags In Discussion Not yet reached consensus labels Aug 13, 2018
@RyanCavanaugh RyanCavanaugh added Too Complex An issue which adding support for may be too complex for the value it adds and removed In Discussion Not yet reached consensus labels Aug 23, 2018
@RyanCavanaugh
Copy link
Member

Would prefer not to add another commandline flag or induce a big breaking change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Add a Flag Any problem can be solved by flags, except for the problem of having too many flags Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds
Projects
None yet
Development

No branches or pull requests

4 participants