Handle breaking change in class property runtime behavior

[RyanCavanaugh]

From https://github.com/Microsoft/TypeScript/issues/12212#issuecomment-428342448 @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

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

TypeScript 3.7

• [x] #33470: emit get/set accessors in declaration files
• [x] #33401: accessors may not override properties and vice versa.
• [x] #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
• [x] #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.

[shrinktofit]

What about decorators? Will the property descriptor is passed to decorator if useDefineForClassFields: true?

[sandersn]

@trotyl @mbrowne The corpus I inspected, our internal test repos + the ones at ~/Typescript/tests/cases/user, shows that people rarely override properties with accessors and vice versa. I tested the code with --useDefineForClassFields, which disallows property/accessor and access/property overrides.

In fact, failures only happened in older code: there was one example of a property-override-accessor in Angular 2's examples. I believe it was intentional, and would only work with [[Set]]. There were 7 examples of accessor-override-property, all of which were trying to make the derived property readonly by only providing get, which would crash with [[Set]], so I think those accessors were never used.

For modern TS, they would instead write

class B {
  x = 1
}
class D extends B {
  readonly x = 2
}

Google and Bloomberg also checked their code bases and found no tricky failures. It's safe to conclude that [[Set]] vs [[Define]] is not practically important.

[sandersn]

Since this targets 3.7.1, I'm going to close this bug. When class fields reaches stage 4, I'll do the final two steps.