In JS, type unioning of this-assignments has undesired behaviour

[sandersn]

function A() {
 this.p = 0
}
A.prototype.m = function(x) {
 this.p = x
}
var a = new A()
a.p // p: any

Expected behavior:
a.p: number

Actual behavior:
a.p: any

This happens because we treat all assignments to the property as declarations and then union their types. And any | T | ... === any

But compare:

function A() {
 this.ps = []
 this.maybe = undefined
}
A.prototype.init = function(x) {
 this.ps = [1,2,3]
 this.maybe = 'just'
}
var a = new A()
a.ps // ps: number[]
a.maybe // maybe: string | undefined

When the initialiser in the constructor has an uninformative type, the unioning can result in a much better type, or at least a less bad type (any). But perhaps the fix here is to handle these uninformative initialisers differently.

[mhegazy]

humm.. this looks right to me.. why is it different from say:

function A(x) {
 this.p = x || 0;
}

[sandersn]

It's different because assignments in a constructor should have higher priority than those in a method. In the any case above, we lose type information from the constructor that is unambiguously more important than the assignment in the method, unlike the this.p = x || 0 case. And this is even worse:

function A(x) {
 this.notANumber = 'one'
}
A.prototype.m = function() {
 this.notANumber = 1
}

I need to see some concrete examples of init-style patterns, but I suspect with those you will not see this-assignments for the same property both in the constructor and in the init method.

[mhegazy]

so you are saying the second assignment should be an error?

[sandersn]

Yes, a type error. This means that we have to resolve the null/undefined/[] initialiser problem in JS+strict, but this is already true for properties that are only set in the constructor and only referenced elsewhere.