Abstract classes that implement interfaces shouldn't require method signatures

[laughinghan]

TypeScript Version: 2.7

Search Terms: abstract class implements interface

Code

interface FooFace {
    foo();
}
abstract class FooClass implements FooFace {
    //         ^^^^^^^^
    // Class 'FooClass' incorrectly implements interface 'FooFace'.
    //   Property 'foo' is missing in type 'FooClass'.
    //
    // unless the following is uncommented:
    //abstract foo();
}

// contrast:
abstract class BarClass {
    abstract bar();
}
abstract class BarSubClass extends BarClass {
    // no `abstract bar();` required
}

Expected behavior:
Abstract classes that implement interfaces don't need to define abstract type definitions to satisfy interface.

Actual behavior:
They do.

Playground Link

Related Issues:

• Implement interface helper does not consider what is already implemented on base classes #19847, where typescript fails to see that a superclass does implement a method (contrast this ticket, where typescript fails to see that a class need not implement a method)

[laughinghan]

Apparently this can be worked-around with class and interface merging:

interface FooFace {
    foo();
}
abstract class FooClass implements FooFace {}
interface FooClass extends FooFace {}

let x: FooClass;
x.foo(); // no error

That seems redundant, though, I still think this should be fixed.

#6413 (comment)

[RyanCavanaugh]

If foo is optional in FooFace, then does FooClass have an implicit abstract foo?(); or not?

[laughinghan]

@RyanCavanaugh Yes, definitely. In my real-world use case (in which I'm currently using the interface/class merging workaround), my interface actually only has optional methods, I just thought I'd leave that out of this example for simplicity. abstract Class implements Interface should imply interface Class extends Interface.

[RyanCavanaugh]

This is all intuitive enough for required members but we can't figure out what should happen to optional members. All choices seem bad.

If we copy down optional members and create optional or non-optional abstract members, then there's no way for your derived class to say "I don't want to implement that member".

If we copy down optional members and create optional concrete members, then we're going to copy down optional properties (I'm presupposing here that differentiating properties and methods is right out) and you won't have any way for you to say "I don't want to have that property".

If we don't copy down optional members, then we've created a "hole" in your type that will allow a derived class to accidently overwrite them with a mismatched type:

interface I { x?: number; }
abstract class A implements I { }
// Would not be an error, but could break at runtime
class B extends A { x: string }

The last problem is of course present today, but doing some of the copying would seem to create the appearance that we were doing more than was actually happening.

Overall it seems like we'd be trading off understandability for convenience here.

[shicks]

There actually is a way to copy optional members concretely and have a subclass declare that they don't want to implement it [playground]:

interface I {
  x?: number;
  m?: (x: I) => void;
}
abstract class A implements I {
  x?: number;          // proposal: implicit if no 'x' is specified
  m?: (x: I) => void;  // proposal: implicit if no 'm' is specified
}
class C extends A {
  x?: never;  // "I don't want an x property"
  m?: never;  // "I'm not going to implement this and nobody else better either"
}
class D extends C {
  x?: string;  // error: Type 'string | undefined' is not assignable to type 'undefined'.
  m(x: I) {}   // error: Type '(x: I) => void' is not assignable to type 'undefined'.
}

Today's state is both error-prone and unergonomic, and the only sound thing to do if a class wants to declare it won't implement an optional property is to carry around the tombstone to guarantee nothing implements it in an incompatible way. Making that (presumably rare case) explicit with a "never" seems like the best approach.

[laughinghan]

@RyanCavanaugh Thank you for the thoughtful response, sorry for my delayed reply.

I don't understand why this option seems bad?

If we copy down optional members and create optional concrete members, then we're going to copy down optional properties (I'm presupposing here that differentiating properties and methods is right out) and you won't have any way for you to say "I don't want to have that property".

@shicks is exactly right: the way you say "I don't want to have that property" should be the same as the way you do so when extending the interface, with never:

interface I { x?: number; }
interface J extends I { x: never }

// contrast:
interface K extends I {}
abstract class L implements I {}
class M implements {}

By contrast, you expect K['x'] to be number | undefined. I'm actually completely surprised that L['x'] and M['x'] are invalid rather than also number | undefined.

[shicks]

For what it's worth, I'm interested in this because Closure Compiler (very recently) allows abstract classes to not redeclare unimplemented interface methods, and I don't want to see code taking advantage of this feature be more problematic to migrate to TypeScript.

@RyanCavanaugh what's the process to actually put together a proposal for this? I think the basis is sound, and this should be perfectly viable.

[cassiodsl]

Another simple option, but it is still redundant is:

export interface IonicLifeCycle {

    ionViewWillEnter();
    ionViewDidEnter();
    ionViewWillLeave();
    ionViewDidLeave();
}

and the abstract class :

export abstract class Base implements IonicLifeCycle {

    abstract ionViewWillEnter();
    abstract ionViewDidEnter();
    abstract ionViewWillLeave();
    abstract ionViewDidLeave();
}