Setting getter property should return error

[mspace]

Bug Report

🕗 Version & Regression Information

4.6.4

⏯ Playground Link

Playground link with relevant code](https://www.typescriptlang.org/dev/bug-workbench/?ts=4.6.4#code/KYDwDg9gTgLgBAYwDYEMDOa4GEIFswpTABiAlksALIQAmwScA3gFDNxxgCuARkqQnADmweKRoAKAJQAuOGhhRSAO0FM27OERicoSuDAAWpNADoAZuWABJGiZgQAyguWCpJhBCUIUMcQHIAWj8AGn0jUyIAN2NSTzgAH3i4Pz9JAG51AF9Wdi5efjgLChtZJU5cbmAoOABeOAAGDNyePgEomM9ZeUUVWuS-DPU81sRPbs4EeyhxZVIYAH5ZAAVCGFIUJAAeHHxCEktqOiQAPkk1DTgAeW4AK2BJk3Q0UkElcUNjUNmYdKycjhaBWQnmAUlkOwIRDIFEO9HOGi0Oj0SmAAHdsHhIfsYbR6OIWBd2EVrDRZB9TMSbMF1BcxLI-Gg-DS4JlfuxstkgA))

💻 Code

export class CompareFileModel {

  public get id(): string {
    return this.fileId.toString().concat('-', this.revision || '');
  }

  public fileId: number = 0;
  public revision: string = '';

  public constructor(init?: Partial<CompareFileModel>) {
    Object.assign(this, init);
  }

  public clone(): CompareFileModel {
    return new CompareFileModel({
      fileId: this.fileId,
      // id is getter property. It should not allow setting getter property
      id: 's'
    });
  }
}

Workbench Repro

🙁 Actual behavior

Typescript reported there is no error.

🙂 Expected behavior

Code should not compile, as we're setting getter property

[MartinJohns]

It's a design limitation. TypeScript does not differentiate between properties with accessors and without.

This is essentially a duplicate of #9726.

[fatcerberus]

Yeah, duplicate of #9726, even though it doesn't look like it at first. The lack of a setter is irrelevant at the point you expect an error since you're just initializing an object literal, which wouldn't call it anyway. Even if there was a setter for id you'd probably still want to exclude that property from init if the setter did anything more complex than this._id = val.

[RyanCavanaugh]

Even if #9726 were implemented, mapped types like Partial would still include non-enumerable properties. Really you'd want an entirely new kind of distinction here, since I don't think the non-enumerability of id is the real crux -- if getters were enumerable tomorrow, the code would still be wrong. You'd want something like Settable<T> that was a mapped type that only produced settable properties, but we don't have write semantics anywhere in relatability.

[fatcerberus]

but we don't have write semantics anywhere in relatability.

So #21759, then.