Check non-undefined properties are initialized in the constructor with `--strictNullChecks`

[mhegazy]

class C {
   p: number; // Should be an error under --strictNullChecks
   method() {
    this.p; 
  }
}

[ahejlsberg]

Since we're not able to track assignment effects between methods, we'd break code that calls a separate initialize method (or some such) to initialize instance data. I'm not a fan of that pattern, but I have certainly run across it.

Also, presumably we want to permit uninitialized properties in abstract classes. That means we'd have to check not just locally declared properties but also inherited properties in non-abstract classes.

[mhegazy]

under a flag then?

[ahejlsberg]

Yeah, probably something like --allowUninitializedProperties, but since it only happens under the new --strictNullChecks I suppose we could wait on adding the flag and gauge the feedback.

[ahejlsberg]

Having looked at several code bases, I don't think it is feasible to implement this feature as we have discussed it. There are simply too many common scenarios where users would need to turn the feature off if we insist that the constructor itself must initialize every non-nullable property. Effectively, it would become more of an irritant than a help.

[malibuzios]

ummm....

class NonAbstractClass { // <-- Non-abstract class, so can be instantiated by itself
    readonly imNotInitialized: number; // <-- can only be initialized here

    constructor() {
        // <-- or here
    }
}

class Base {
    readonly imNotInitializedToTheRightType: any;

    constructor() {
        this.imNotInitializedToTheRightType = "hi";
    }
}

class Derived extends Base {
    readonly imNotInitializedToTheRightType: number; // <-- is this initialized?

    constructor() {
        super();
    }
}

[malibuzios]

@ahejlsberg

I think I've shown one common scenario where this would be a help, not an irritant: namelyreadonly members in a non-abstract class, and one less common, but probably more 'severe' one: inherited members initialized to incompatible or less capable types than the type they are redeclared to in a derived class.

I haven't yet got any response from you on this. Why would you think it would be an irritant here?

(also, I haven't got any responses for the questions about inheritance of readonly members by writable members and vice-versa. It has been a week so far, and neither you or anyone of the team have shown serious intentions to engage in that discussion. I can't really see a reason why not - if your original reasoning was solid it should be relatively easy to explain..)