Proposal: allow ambient property declarations to override accessors as well

[sandersn]

Currently, this pattern gives an error, but arguably shouldn't:

class B {
  get p() { return B.s } // inferred p: {}
  static get s() { return {} }
}
class C extends B {
  declare readonly p: { x: 1 }
}

Expected behavior:

No error, and C.p: { x: 1 } (but is still an accessor for emit and checking purposes). That is, this should be legal:

class D extends C {
  get p() { return { x: 1 } as const }
}

Actual behavior:

Error, and C.p is a property, not an accessor.

[sandersn]

Based on comments here: #37894 (comment)

@DanielRosenwasser @rbuckton we should discuss this.

Related: a proposal to add a flag, moving the error underneath strict: #39401. That issue suggests that perhaps this error exemption should apply to decorated properties as well as ambient properties.

[InExtremaRes]

@sandersn I have just opened an stackoverflow question related to this. The TL;DR is:

I have a base class with an accessor in the prototype (a getter) and I want a derived class to initialize an own property in the instance, overriding the accessor. Basically something like this (using useDefineForClassFields: true):

class Base {
    get foo() { return "getter"; }
}

class Deriv extends Base {
    readonly foo: string = 'own property';
}

TS fails with error TS2610. I understand that even if I have a setter in Base it won't be called by the constructor of Deriv, and that is exactly what I need. Base could have a default algorithm for foo that I don't need for Deriv, the latter can just go with a plain own (enumerable) data property in every instance.

Is this case related to this issue or should I open a new one?

[trymoto]

Would love this to be implemented