This PR is part of the migration from [[Set]] semantics to [[Define]] semantics.#27644 tracks the complete migration. This PR includes steps 1-4 for Typescript 3.7:

• Always emit accessors in .d.ts files #33470: emit get/set accessors in declaration files. This means that 3.7-emitted d.ts files will be incompatible with 3.5 and below.
• 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 insertsdeclare 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 tofalse
  • Declaration emit is the same regardless of the flag's value.
• Bonus: The error "properties/accessors aren't allowed to override methods" was not reported from 3.0 onward. This PR also fixes that error.

Tasks from the design meeting:

• Abstract properties with initialisers generate code, so should generate the error after all.
• ES3 should set+require useDefineForClassFields=false
• useDefineForClassFields=true should also use defineProperty for method emit so we can set enumerability correctly.
• change flag name to useDefineForClassFields and flip polarity from legacyClassFields

Accessors may not override properties and vice versa

Briefly, properties can now only override properties, and accessors can only override accessors. The tests come from the user-submitted horrorshow parade in#27644. Thanks to all who contributed there.

Exceptions

1. If the base property is abstract or in an interface, there is no error unless the abstract base property has an initialiser.
2. If the symbol has both Property and Accessor set, there is no error. (I'm not sure when this can happen, although@weswigham says he can produce a Javascript example pretty easily.)

Motivation

Accessors that override properties have always been error-prone with [[Set]] semantics, so these new errors are useful with [[Set]]or [[Define]] semantics. For example, base-class properties call derived accessors, which may be unexpected. The code below prints2, the derived value, but italso printsset 1. That's because the basep = 1 calls derived accessorset p.

classB{p=1}classDextendsB{_p=2getp(){returnthis._p}setp(value){console.log('set',value);this._p=value}}vard=newD()console.log(d.p)

In fact, if the derived class attempts to makep readonly by leaving offset p, the code crashes with"Cannot set property p of #<D> which has only a getter." This should always have been an error. However, because we haven’t given errors before, and because fixing the errors is likely to be difficult, we probably would not have added them otherwise, or added them in so many cases. Here are some examples of code that will be tricky to change:

classCleverBase{getp(){// caching, etc.}setp(){}}classSimpleextendsCleverBase{p='just a value'}

CleverBase is a framework class that intends to cache or transform the value provided bySimple.Simple is written by a framework user who just knows that they need toextend CleverBase and provide some configuration properties. This pattern no longer works with [[Define]] semantics. I believe the Angular 2 failure I found below is similar to this case.

classLegacyBase{p=1}classSmartDerivedextendsLegacyBase{get(){// clever work on get}set(value){// additional work to skip initial set from the base// clever work on set}}

This code is the same as the first example — accessors override a property — but the intent is different: to ignore the base's property. With [[Set]] semantics, it's possible to work around the initial set from the base, but with [[Define]] semantics, the base property will override the derived accessors. Sometimes a derived accessor can be replaced with a property, but often the accessor needs to run additional code to work around base class limitations. In this case, the fix is not simple. I saw this in a couple of Microsoft apps, and in one place it had a comment "has to be a getter so overriding the base class works correctly".

How to fix the errors

Property overrides accessor

classCleverBase{_p:unknowngetp(){return_p}setp(value){// cache or transform or register or ..._p=value}}classSimpleUserextendsCleverBase{// base setter runs, caching happensp="just fill in some property values"}

SimpleUser will have an error on the property declarationp. The fix is to move it into the constructor as an assignment:

classSimpleUserextendsCleverBase{constructor(){// base setter runs, caching happensthis.p="just fill in some property values"}}

SinceCleverBase declaresp, there's no need forSimpleUser to do so.

Accessor overrides property

classLegacyBase{p=1}classSmartDerivedextendsLegacyBase{get()p{// clever work on get}set(value)p{// additional work to skip initial set from the base// clever work on set}}

SmartDerived will have an error on the get/set declarations forp. The fix is to move them into the constructor as anObject.defineProperty:

classSmarterDerivedextendsLegacyBase{constructor(){Object.defineProperty(this,"p",{get(){// clever work on get},set(value){// clever work on set}})}}

This doesn't have exactly the same semantics; the base never calls the derived setter forp. If the original setter does have skip-initial-set code to work around the current weird Typescript semantics, that code will need to be removed. However, all the real examples I saw were just using accessors to make the property readonly, so they could instead use a readonly property.

Uninitialised property declarations may not override properties

Briefly, uninitialised property declarations that must now use new syntax when the property overrides a property in a base class. That's because when Typescript supports [[Define]] semantics, previously uninitialised property declarations will instead have an initial value ofundefined. This will be a major breaking change:

classB{p:number}classCextendsB{p:256|1000// use whatever value you need here; it}

Previously this emitted

classB{}classCextendsB{}

When Typescript supports [[Define]] semantics, it will instead emit

classB{p}classCextendsB{p}

which will give bothB andC and propertyp with the valueundefined. (This is an error today withstrictNullChecks: true.)

The new syntax will cause Typescript to emit the original JS output:

classB{p:number}classCextendsB{declarep:256|1000}

This PR adds an error prompting the author to add the new syntax in order to avoid the breaking change. As you can see from the baselines, this error is pretty common. From my first run of our extended test suites, it looks pretty common in real code as well.

Note that the compiler can only check constructors for initialisation whenstrictNullChecks: true. I chose to be conservative and always issue the error forstrictNullChecks: false.

Other ways to fix the error

1. Make the overriding property abstract.
2. Make the base property abstract.
3. Give the overriding property an initialiser.
4. Initialise the overriding property in the constructor -- but this only works with"strictNullChecks": true.

Notes

1. Adding a postfix-! willnot fix the error;! is always erased, so, in the last example,p!: 256 | 1000 would still result inp === undefined for [[Define]] semantics.
2. You can adddeclare to any uninitialised property, even if it's not an override. I previously had a check that prevented this, but I think an easy upgrade is valuable (you canalmost write a regex for it).