Readonly properties can be modified in derived classes

未指定源文件或测试。先从链接的 Playground 复现和 readonly 修饰符及接口文档开始，然后追踪编译器如何处理类继承中的 readonly 成员；当预期规则确定，并且该行为由文档一致的回归测试覆盖时，即视为完成。

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.

TypeScript Version: 3.3.0-dev.201xxxxx

Search Terms: final readonly properties derived inherits

Code

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:
here

Note that in the documentation 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 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.