Inherited typing for class property initializers

[RyanCavanaugh]

Problem

Initializing a class member with things like { }, null, undefined, or [] has unexpected behavior.

class Base {
  favorites = ["red", "blue"];
}
class Derived extends Base {
  favorites = [];
  constructor() {
    this.favorites.push('green'); // Can't push string onto never[], wat?
  }
}

interface Settings {
  size?: number;
  color?: string;
}
class Base {
  settings: Settings = { size: 42 };
}
class Derived extends Base {
  settings = { };
  constructor() {
    if (big) this.settings = { siz: 100 }; // no error, wat?
  }
}

Solution

New rule: When a class property is initialized with exactly null, undefined, { }, or [], the type of the property is taken from the same property of the inherited type (if one exists), rather than the type of the initializer.

The inherited type is B & I1 & I2 & ... where B is the base class and I1, I2, ... are the implemented interfaces of the class.

Examples

interface Positionable {
  position: string | null;
}
class MyPos implements Positionable {
  position = null;
  setPos(x: string) {
    this.position = x;
  }
  getPos() {
    return this.position.subtr(3); // error detected
  }
}

class Base {
  items = ['one'];
}
class Derived extends Base {
  items = []; // no longer an implicit any
}
var x = new Derived();
x.items.push(10); // Error as expected

Bad Ideas We Thought Were good

Contextual typing plays poorly with other behavior such as unit type positions. Consider

enum E { A, B, C }
class Base {
  thing = E.A;
}
class Derived extends Base {
  thing = E.B;
  change() {
    this.thing = E.C; // Error! wat
  }
}

This turns into a big problem because the E.B expression is contextually typed by the unit-like type E.A | E.B | E.C and so acquires the specific type E.B rather than the intended type E! Daniel found this break in Azure.

/cc conspirators @DanielRosenwasser @sandersn

[sandersn]

#6118 is the first failed attempt, which has further discussion of the problems with contextual typing. (All 3 previous attempts were based on contextual typing.)

[DanielRosenwasser]

I'm actually okay with this idea - it reflects a lot of the same views we're taking with open/expando types.

[RyanCavanaugh]

TODO: Try blindly taking the base class's type and see what happens in the RWC

[sandersn]

This is basically what the summary of #6118 covers, except that it was for all properties, initialised or not. You intend to try with just properties that are initialised to [], {}, null, undefined, right?

[RyanCavanaugh]

Nope, all properties

[sandersn]

How is that different from this summary on #6118, then?

[RyanCavanaugh]

Make the declared type of the derived property the type of the base type's property, as if you had written field: typeof super.field = expr), rather than contextually type expr with typeof super.field

[sandersn]

I just realised I should have linked to #10610. Confusingly, my good/bad/ugly post in #6118 actually refers to an old version of that PR, which does basically what you describe, and as far as I recall, still hits some problem.

@DanielRosenwasser, you actually RWC with #10610. Do you have notes on the problem it hit? I remember it being literal-type related, so maybe it would be different now that we have literal types everywhere.