Error (2320) when extending interfaces where a property is both readonly and readwrite.

[denis-migdal]

🔎 Search Terms

Related issues:

• Rules for intersection types are inconsistent with rules for implementing multiple interfaces. #4278
• Interface with readonly property is assignable to interface with mutable property #13347

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

Playground Link

💻 Code

interface A { readonly foo: number; }
interface B { foo: number; }

interface C extends A, B {}

🙁 Actual behavior

Interface 'C' cannot simultaneously extend types 'A' and 'B'.
  Named property 'foo' of types 'A' and 'B' are not identical.(2320)

🙂 Expected behavior

No error.

Additional information about the issue

As far as I understand, readonly isn't a constraint, but an interface specification.
Meaning, that readonly foo: number is almost equivalent to:

get foo(): number;

Not to:

get foo(): number;
set foo(_: never): void; // If I'm not mistaken this should forbid assignations.

(TBH, a read keyword would be less confusing than readonly.)

Therefore, here, I want to merge:

get foo(): number;

With:

get  foo(): number;
set foo(f: number): void;

We can see it as:

• "merging" 2 identical getters, which cause no issue.
• adding an additional property (like we could add a method) : the setter.

However, the latter causes an issue when it shouldn't. This is just adding something.

Note: TS requires the 2 types of foo to be strictly identical.
But, when one is readonly, then it could accept the second to be a specialization of it (i.e. assignable to the readonly version).

Indeed, the resulting interface would still be assignable to the first one.

[denis-migdal]

I also noticed that, in the resulting interface, the property might be readonly depending on the order of the extends.

I'm guessing TS picks the first definition, assuming both definitions are identical, when it should picks the non readonly one (or the more specialized if both are readonly).

Playground Link

interface A {
    get foo(): number;
}
interface B {
    get foo(): number;
    set foo(a: number);
}

interface AB extends A, B {}
interface BA extends B, A {}

let ab!: AB;
let ba!: BA;

ab.foo = 3; // error
ba.foo = 3; // ok

[denis-migdal]

Not sure if related:

Playground Link

interface I {
   get foo(): number;
   set foo(v: number);
}

abstract class A {
    get foo() { return 4; }
}

class B extends A implements I {
    // set foo is not implemented, should raise an error.
}

const b = new B();
b.foo = 4; // error

Note: in the exemple above, TS should tell us to add set foo(), but also to re-define get foo().

Playground Link

class A {
    get foo() { return 4 }
    set foo(a: number ){}
}

class B extends A {
    // TS should ask us to re-declare get foo.
    set foo(a: number) {}
}

const b = new B();
console.warn( b.foo ); // undefined

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Similar Issues

Here are the most similar issues I found

• (72%) microsoft/typescript#11578: Implements readonly property should be readonly
• (71%) microsoft/typescript#11484: readonly flag not inherited
• (70%) microsoft/typescript#7987: Error when assigning to read-only interface properties from merged interfaces
• (69%) microsoft/typescript#34274: Conditional type extends check ignores readonly constraint
• (69%) microsoft/typescript#45122: Intersection between separate types with getter and setter does not allow assignment to property
• (69%) microsoft/typescript#14882: Duplicate identifier error with readonly/getter, class and merged interface
• (68%) microsoft/typescript#61344: Intersection for same key read-only property maybe wrong
• (68%) microsoft/typescript#43036: Readonly fields and getter-only class members are not compatible when merging declarations
• (68%) microsoft/typescript#39871: A readonly interface property can be implmented as writeonly class property?
• (68%) microsoft/typescript#28906: Readonly<T> should not be assignable to T without a type assertion
• (67%) microsoft/typescript#33234: variance of subtyping
• (67%) microsoft/typescript#13787: Readonly<ConcreteType & GenericType> can't resolve member's type
• (67%) microsoft/typescript#40145: Type check for interface does not preserve "readonly"
• (67%) microsoft/typescript#43224: Interface implement with read only properties.
• (67%) microsoft/typescript#20093: Class without setter property incorrectly allowed to implement interface

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

[denis-migdal]

This time, no clear duplicates to the 4 things I brought up:

• 1 brought up a design oversight and was fixed. My issue may be coming from the same kind of oversight, but in different cases.
• 1 may have a similar cause to the 2th, but isn't the same case (intersection vs implementation).
• 1 has a similar code to the 4th but didn't bring up the issue.
• 1 is the opposite of 4th (get vs set), but was wrongfully closed.
• several issues shows that readonly is confusing.

Related to bug 1: implementing 2 interfaces

• none.

Related to bug 2: readonly depends on the implemented interfaces order

• (68%) microsoft/typescript#61344: Intersection for same key read-only property maybe wrong
  => Not the same case (implements vs intersection), but maybe a similar cause.

Related to bug 3: set not implemented should raise an error

• none.

Related to bug 4: set overridden should require to override get

• (68%) microsoft/typescript#39871: A readonly interface property can be implmented as writeonly class property?
  => Same code, but doesn't bring up the fact that TS should require to override get.

• (67%) microsoft/typescript#20093: Class without setter property incorrectly allowed to implement interface
  => The opposite case, was wrongfully closed, TS should require to override set.

Design oversight, and currently fixed

• Intersection between separate types with getter and setter does not allow assignment to property #45122
  => The bug I described may be coming from the same kind of oversight, but contrary to these issues hasn't be fixed yet.

Confusion: readonly constraint vs interface specification:

• (72%) microsoft/typescript#11578: Implements readonly property should be readonly
• (71%) microsoft/typescript#11484: readonly flag not inherited
• (67%) microsoft/typescript#43224: Interface implement with read only properties.

Confusion: readonly vs final

• (70%) microsoft/typescript#7987: Error when assigning to read-only interface properties from merged interfaces

Design limitation : readonly assignable to non-readonly.

• (69%) microsoft/typescript#34274: Conditional type extends check ignores readonly constraint
• (68%) microsoft/typescript#28906: Readonly should not be assignable to T without a type assertion
• (67%) microsoft/typescript#40145: Type check for interface does not preserve "readonly"

Unrealated to readonly:

• (69%) microsoft/typescript#14882: Duplicate identifier error with readonly/getter, class and merged interface
• (67%) microsoft/typescript#33234: variance of subtyping
• (67%) microsoft/typescript#13787: Readonly<ConcreteType & GenericType> can't resolve member's type