Handle breaking change in class property runtime behavior

[RyanCavanaugh]

From #12212 (comment) @joeywatts:

class A {
    property = 'some string';
}
class B extends A {
    property;
}
const instanceB = new B();
// "some string" or "undefined" ?
console.log(instanceB.property);

It appears from the current definition at https://github.com/tc39/proposal-class-fields that this code will print undefined.

If the proposal advances further with these semantics, we'll need to figure out a mitigation strategy, preferably sooner rather than later.

One option is to make the code as written a type error for ~2 versions and force people to write an explicit = undefined initializer, then remove the error.

Edit [@sandersn]:

Here is the current plan, together with what has happened so far.

TypeScript 3.6

• Allow accessors in ambient class declarations #32787: allow accessors like declare class C { get p(): number; } (and set as well)
• No changes to .js emit yet
• No changes to .d.ts emit yet

TypeScript 3.7

• Always emit accessors in .d.ts files #33470: emit get/set accessors in declaration files
• Disallow property/accessor overrides #33401: accessors may not override properties and vice versa.
• Disallow uninitialised property overrides #33423: uninitialised properties may not override properties.
  • Introduce new syntax, class C extends B { declare x: number }
  • Introduce a codefix that inserts declare where needed.
  • This declaration is erased, like the original declaration in old versions of TS
• Add useDefineForClassFields flag for Set -> Define property declaration #33509 Introduce a new flag, useDefineForClassFields.
  • When "useDefineForClassFields": false:
    • Initialized fields in class bodies are emitted as constructor assignments (even when targeting ESNext).
    • Uninitialized fields in class bodies are erased.
    • The preceding errors are silenced.
  • When "useDefineForClassFields": true:
    • Fields in class bodies are emitted as-is for ESNext.
    • Fields in class bodies are emitted as Object.defineProperty assignments in the constructor otherwise.
  • In 3.7, "useDefineForClassFields" defaults to false
  • Declaration emit is the same regardless of the flag's value.

TypeScript 3.8

(or, the first version after class fields reaches Stage 4)

• "useDefineForClassFields" defaults to true when targetting ESNext.
• issue new errors as suggestions with codefixes, even when "useDefineForClassFields": false.

[littledan]

I am happy to see TS looking into this important compatibility issue. This plan sounds good to me.

Another potential incompatibility is that TC39's fields are defined with Object.defineProperty, not =, so setters defined in a superclass will not run.

[RyanCavanaugh]

@littledan this is a bit of a compat nightmare for us and it'd be great to understand why initializers are optional in the current proposal. Why would someone write an initializer-free non-private declaration in the first place? Staking out an own property with the implicit value undefined seems like an odd bit of sugar to have when it creates a footgun for derived classes as a trade-off.

[bakkot]

@RyanCavanaugh:

class Foo {
  val;
  constructor({ val }) {
    this.val = val;
  }
}

I expect to see a lot of code like the above. It's really nice to be able to see the shape of the class without having to look in the constructor, but sometimes the value which goes into the field depends on arguments to the constructor.

[RyanCavanaugh]

Why is that kind of construct even desirable without static (or even dynamic!) enforcement? It's just a comment written in a different syntax - destined to be out of date and out of sync with what actually happens in the constructor

[ljharb]

fwiw static enforcement of that pattern is trivially possible with eslint, with or without an explicit initializer.

[bakkot]

No, it's meaningfully different: because it uses [[DefineOwnProperty]] semantics, it guarantees the property is an own data property, rather than risking triggering setters on a superclass.

You can of course put a Object.defineProperty in the constuctor, but that's... not great.

---

I recall we discussed the possibility of requiring initializers at some point, though I can't dig that up just now.