Repository: TypeScript
Issue: Readonly properties can be modified in derived classes
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->
This issue is created even if there was a pretty complete issue about the purpose of the readonly keyword ( https://github.com/Microsoft/TypeScript/issues/8496#issuecomment-217500742 ) and I'll just quote @RyanCavanaugh :
> Basically we see properties as "possibly readonly" or "definitely readonly", and allow assignments from definitely-readonly things to possibly-readonly things.

I totally agree that we must prevent codes from libraries and/or node modules, as still today there's modules that doesn't include d.ts files and the DefinitelyTyped repo doesn't have 100% of updated d.ts files.

BUT as the main purpose was to do a compromise, let's add a compromise over the compromise, see the code below to understand why we should make the user more careful about mutating a `readonly` property when deriving a class.
<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.3.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** final readonly properties derived inherits

**Code**

```ts
abstract class Pet {
    protected abstract race: string;

    protected abstract sayMyRace(): void;
}

class Dog extends Pet {
    protected readonly race: string = "Dog";

    sayMyRace() {
        console.log(this.race);
    }
}

class NotADog extends Dog {
    protected readonly race: string = "Robot";
}

const scooby = new Dog();
scooby.sayMyRace();

const marvin = new NotADog();
marvin.sayMyRace();
```

**Expected behavior:**
Error saying that race in `NotADog` cannot be modified as it was already declared in class `Dog` and we set the same attributes in both cases, meaning we do want to override a constant.
**Actual behavior:**
Property is overwritten, ignoring the readonly property from the already existing parent's property.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
[here](https://www.typescriptlang.org/play/#src=abstract%20class%20Pet%20%7B%0D%0A%20%20%20%20protected%20abstract%20race%3A%20string%3B%0D%0A%0D%0A%20%20%20%20protected%20abstract%20sayMyRace()%3A%20void%3B%0D%0A%7D%0D%0A%0D%0Aclass%20Dog%20extends%20Pet%20%7B%0D%0A%20%20%20%20protected%20readonly%20race%3A%20string%20%3D%20%22Dog%22%3B%0D%0A%0D%0A%20%20%20%20sayMyRace()%20%7B%0D%0A%20%20%20%20%20%20%20%20console.log(this.race)%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0Aclass%20NotADog%20extends%20Dog%20%7B%0D%0A%20%20%20%20protected%20readonly%20race%3A%20string%20%3D%20%22Robot%22%3B%0D%0A%7D%0D%0A%0D%0Aconst%20scooby%20%3D%20new%20Dog()%3B%0D%0Ascooby.sayMyRace()%3B%0D%0A%0D%0Aconst%20marvin%20%3D%20new%20NotADog()%3B%0D%0Amarvin.sayMyRace()%3B)

Note that in the [documentation](https://www.typescriptlang.org/docs/handbook/classes.html#readonly-modifier) the example shows an error when trying to mutate the property created in the class.

I'm not asking to put a check rule on every keyword in every line of code, but to accept that if a class have a readonly property, nobody can mutate it from outside, I'm not talking about the interfaces and/or declaration file to help to make the compromise, but the Typescript [documentation](http://www.typescriptlang.org/docs/handbook/interfaces.html) state:
>The easiest way to remember whether to use readonly or const is to ask whether you’re using it on a variable or a property. Variables use const whereas properties use readonly.

If a property with readonly is a variable with const, then we must keep this in line and prevent any mutation from a class property to another class property, at least that would allow to add a safety check in the code.

Also the documentation regarding the readonly properties in Interfaces state that
> Some properties should only be modifiable when an object is first created.

If the team says that a mutation between an explicitly typed `readonly` property from a class to a subclass is normal as the compromise was done and that changing the rules would break the declaration files (even though two years had past)

So to sum up : 
I open this issue as a bug because the documentation states that a readonly property is a constant variable, and that based on the few informations about it (still from the documentation), this is not the expected behavior.

I also considered the previous discussion and the compromise made to prevent any blocking backward compatibility, and asking only to use the readonly check rule from class to class by default, and allow more in a tsconfig rule later.