Repository navigation
A class can implement an interface with only a getter for a non-read-only field #49345
Description
Bug Report
🔎 Search Terms
interface, class, getter, setter, readonly
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about read-only fields, getters and setters
⏯ Playground Link
Playground link with relevant code
💻 Code
interface X {
field: number;
}
class Y implements X {
get field() { return 1 };
// set field(x: number) {}
}
// this generates an error: "cannot assign to field because it is a read-only property"
const y: Y = { field: 1};
y.field = 3;
// but this is fine
const x: X = y;
x.field = 2;🙁 Actual behavior
A class is considered to implement an interface when it includes only a getter for that interface's field; no error is generated.
🙂 Expected behavior
Instances of this class can't be substituted for instances of this interface, so the class definition should generate an error.
Since the interface implies that one can both get and set field, the class should be considered incomplete without both a getter and setter for field. Given a member of the interface, setting field typechecks, but given a member of the class, it throws an error.
The example is a minimal repro from a real bug we found that followed this pattern, and we were surprised that it was allowed.
Reacted by mlemoine-clgx
Activity
fatcerberus commentedon Jun 2, 2022
Not saying this isn't a bug, but note that in general TypeScript's readonly guarantees aren't very strong and the type system largely acts as if objects were passed by value, so this issue is just scratching the surface of the tip of that iceberg:
Your issue is in fact a symptom of the above:
Yis assignable toX(getter-only accessors are equivalent toreadonlyin the type system), so is considered a valid implementation of the interface.RyanCavanaugh commentedon Jun 2, 2022
A useful mental model is that properties are "read-only" from the perspective of how the type system treats them, but allows writes anyway unless they're marked
readonly. There are any number of soundness holes as a result (subtyping being the obvious one, and indeed you can think offieldas having a setter of typenever).bendmorris commentedon Jun 2, 2022
Just so I'm clear - is this a known limitation that potentially will be fixed in the future, or a known limitation that we don't want to do anything about?
RyanCavanaugh commentedon Jun 2, 2022
The problem is social, not technical. This is easily "fixable" in principle by adding a
--strictReadonlyflag (maybe a few dozen lines of code at most), or a strict property variance flag, but this setting wouldn't be usable until everyone updated tens of thousands of definition files to clarify whether any given property is supposed to be mutable or not. There's just not a lot of appetite for forcing literally everyone who uses TS to start thinking about that problem. So I don't think it's likely to happen any time soon, if ever.fatcerberus commentedon Jun 2, 2022
I prefer to think of it more as the type system assuming pass-by-value semantics (i.e. assignment implies a copy is made), as this is the only way I can justify
{ readonly x: "foo" | "bar" } -> { x: string }being a legal assignment. And to be fair this does accurately model most POJO scenarios, but kind of falls apart when used to model inheritance.typescript-bot commentedon Jun 4, 2022
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.