Add support for abstract constructor types

[rbuckton]

This adds support for the abstract keyword on constructor types and construct signatures, allowing you to indicate the signature is abstract. This also updates the definitions for InstanceType and ConstructorParameters to use the abstract modifier:

Syntax

// constructor types
type T1 = abstract new () => any;

Semantics

• Non-abstract constructor types are assignable to abstract constructor types if they would otherwise be assignable.
• Abstract constructor types are not assignable to non-abstract constructor types.
• Values with types containing abstract constructor types cannot be instantiated via new (this previously only applied to abstract classes)

Examples - Basic Usage

type Constructor<T> = new (...args: any[]) => T;
type AbstractConstructor<T> = abstract new (...args: any[]) => T;
interface Obj<T> {
  x: T;
}

declare let c: Constructor<Obj<number>>;
declare let a: AbstractConstructor<Obj<number>>;

// assignability
a = c; // ok, a non-abstract constructor type can be assigned to an abstract constructor type
c = a; // error, an abstract constructor type cannot be assigned to a non-abstract constructor type

// new expression
new c(); // ok
new a(); // error, cannot create an instance of an abstract class

// inference and conditional types
type T1 = InstanceType<typeof c>["x"]; // number
type T2 = InstanceType<typeof a>["x"]; // number

Examples - Mixins

interface Mixin { ... }
abstract class Base { ... }

declare function Mixin1<TBase extends new (...args: any[]) => {}>(base: TBase):
    TBase & (new (...args: any[]) => Mixin);

class Sub1 extends Mixin1(Base) { }
//                        ^^^^ TS2345: Argument of type 'typeof Base' is not assignable 
//                                     to parameter of type 'new (...args: any[]) => {}'.
//                                     Cannot assign an abstract constructor type to a 
//                                     non-abstract constructor type.

declare function Mixin2<TBase extends abstract new (...args: any[]) => {}>(base: TBase):
    TBase & (new (...args: any[]) => Mixin);

class Sub2 extends Mixin2(Base) { } // Ok

Fixes #26829
Fixes #35576

[rbuckton]

CC: @weswigham, @RyanCavanaugh, @DanielRosenwasser (as suggested reviewers is not working).

[ajafff]

Does this also support mixins with abstract classes? Could you add a test for that, too?

[rbuckton]

I'm going to revert support for abstract construct signatures in favor of investigating class type expressions:

// [source.ts]
function MyMixin<TBaseClass extends abstract new (...args: any[]) => any>(
  baseClass: TBaseClass
) {
  abstract class MyMixinClass extends baseClass {
    abstract abstractMethod(): void;
  }
  return MyMixinClass;
}

// [output.d.ts]
declare function MyMixin<TBaseClass extends abstract new (...args: any[]) => any>(
  baseClass: TBaseClass
): abstract class extends TBaseClass {
  abstract abstractMethod(): void;
};

[rbuckton]

Build failures seem to be due to the fact that eslint isn't handling the construct signatures having modifiers in lib/es5.d.ts so I'm reverting that part for now.

[trusktr]

declare function MyMixin<TBaseClass extends abstract new (...args: any[]) => any>(baseClass: TBaseClass)

If the constraint for TBaseClass is an abstract constructor, can we still base a non-abstract class for baseClass?

It won't be helpful if we're stuck with either abstract or not-abstract.

I think what people really want is that if they pass in an abstract class, then the mixin result is an abstract class (unless the mixin class implements the methods/properties), or if they pass a non-abstract class, then the mixin result is not abstract.

Otherwise the usability of mixins would be inflexible.

The following code has some type information omitted (like plain JS) so that I can clearly show the intention:

abstract class Foo {
  abstract fooMethod(): void
}

function CoolMixin(Base) {
  return class Cool extends Base {
    coolMethod() {}
  }
}

class MyClass extends Foo {
  // Required to implement the abstract fooMethod here.
  // ...
}

class MyOtherClass extends CoolMixin(Foo) {
  // Should also be required to implement the abstract fooMethod here.
  // ...
}

As a workaround, we could do the following but it is less ideal:

abstract class Foo {
  abstract fooMethod(): void
}

function CoolMixin(Base) {
  return class Cool extends Base {
    coolMethod() {}
  }
}

class MyClass extends Foo {
  // Required to implement the abstract fooMethod here.
  // ...
}

class _MyOtherClass extends Foo {
  // Required to implement the abstract fooMethod here.
}

class MyOtherClass extends CoolMixin(_MyOtherClass) {
  // ...
}

And if the mixin returns an abstract class, it should inherit abstractedness. So,

abstract class Foo {
  abstract fooMethod(): void
}

function OtherMixin(Base) {
  return abstract class Other extends Base {
    otherMethod() {}
  }
}

class MyClass extends Foo {
  // Required to implement fooMethod here.
  // ...
}

class MyOtherClass extends OtherMixin(Foo) {
  // Required to implement fooMethod and otherMethod here.
  // ...
}

class Bar {
  barMethod() {...}
}

// the previous OtherMixin application accepted an abstract class, and now this application accepts a non-abstract class:
class MyNextClass extends OtherMixin(Bar) {
  // Required to implement otherMethod here, and the barMethod is inherited.
  // ...
}

Note that last example in particular accepts both abstract and non-abstract base classes (I didn't show an example of CoolMixin accepting a non-abstract class but that should work too).

I believe that's what we should aim for in TypeScript, otherwise we're not effectively modeling plain JS in the most useful way.

Mixins are suppose to be mixed-and-matched, but if we can not work with abstract in a flexible way, we won't be able to mix-and-match mixins.

I'm merely a TypeScript end user, but I hope some solution can be found so that mixins are as convenient as they are in plain JS but with structural types in place.

[rbuckton]

@typescript-bot pack this

[typescript-bot]

Heya @rbuckton, I've started to run the tarball bundle task on this PR at 2e77e93. You can monitor the build here.

[typescript-bot]

Hey @rbuckton, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/84547/artifacts?artifactName=tgz&fileId=78EEF1EB3E873A239A07C29FA531FBC2DFBC4D34D336DA97287D6ED06314D6F302&fileName=/typescript-4.1.0-insiders.20200908.tgz"
    }
}

and then running npm install.

[rbuckton]

@trusktr: A new () => T type is assignable to an abstract new () => T type. A mixin definition that uses something like <TBase extends abstract new (...args: any[]) => {}>(base: TBase) { ... } will work for both abstract and non-abstract superclasses:

function Mixin<TBase extends abstract new (...args: any[]) => {}>(base: TBase) {
    abstract class M extends base {
    }
    return M;
}

abstract class AbstractBase {
    abstract m(): number;
}

class ConcreteBase {
    m(): number { return 1;}
}

// error: C must implement abstract method `m`
class C extends Mixin(AbstractBase) {
}

// no error
class D extends Mixin(ConcreteBase) {
}

[rbuckton]

Although it should probably be an error for class M extends base, since M should also be marked abstract.

[orta]

@typescript-bot pack this

[DanielRosenwasser]

I think the one thing that I'm still a little bit surprised about is that there's no way to rewrite the following example

abstract class Foo {
  abstract fooMethod(): void
}

function extendFoo(FooCtor: abstract new () => Foo) {
  // Error! Must implement 'fooMethod'
  return class extends FooCtor {
  }
}

in such a way that Foo is declared as any other object type like an interface.

The first reason I think this is weird is because abstract doesn't get funneled around as any other modifier, and so this gets a little funky as you try to do algebra over the properties.

abstract class Foo {
  abstract fooMethod(): void
}

// Homomorphic mapped type over `Foo`
type CopyFoo = {
    [K in keyof Foo]: Foo[K]
}

function extendFoo(FooCtor: abstract new () => CopyFoo) {
  // No error now!
  return class extends FooCtor {
  }
}

The second is that in order to model this sort of pattern, you always have to declare a class, even if you won't necessarily be extending from that class (and even if nobody is going to be extending from that class). That on its own feels kind of strange in our mostly-structural type system.

But I don't really know the right way to reconcile all of this - would "fixing" these issues mean that interfaces would have to allow abstract members? Would interfaces themselves need to be declared abstract? And how would this work with class/interface merging?

[rbuckton]

The issue is that we don't (yet) have a way to represent this type in any other way. #41587 will eventually add syntax that would permit this in type-space:

type TFoo = typeof abstract class {
  constructor();
  abstract fooMethod(): void;
};

function extendFoo(FooCtor: TFoo) { ... }

However, typeof class doesn't solve the issue that abstract new is intended to solve. With typeof class, you still cannot infer the instance type, so there's no version of InstanceType<T> that could use typeof class on its own. However, with abstract constructor types, we can eventually rewrite InstanceType<T> as this:

type InstanceType<T extends abstract new (...args: any) => any> = T extends abstract new (...args: any) => infer R ? R : any;

With a new InstanceType, we can have a type definition that preserves abstract without introducing a class in the value-space:

type TFooInst = InstanceType<typeof abstract class {
  abstract fooMethod(): void;
}>;

In the end we will need both abstract constructor types and typeof class, but one is not dependent on the other. The main reason to ship abstract constructor types a version ahead of typeof class has to do with our dependency on typescript-eslint. Since typescript-eslint won't understand abstract new until it ships in a stable release, we need abstract new to ship one version prior to changing InstanceType to avoid lint errors in our own codebase. That way, by the time typeof class lands, we'll have a version of InstanceType that can be used in the way mentioned above.

Whether or not we eventually do something else for abstract in regards to interfaces or our type-algebra may be related to this feature, but is essentially out of scope as any decisions we make there are unlikely to impact the behavior of this feature. The only real cross-cutting concern I see would be that we might eventually loosen the restriction that classes extending from abstract new base types must themselves be declared abstract (instead basing it off of whatever new rules we come up with), and that wouldn't be a breaking change.

[rbuckton]

I think the one thing that I'm still a little bit surprised about is that there's no way to rewrite the following example

abstract class Foo {
  abstract fooMethod(): void
}

function extendFoo(FooCtor: abstract new () => Foo) {
  // Error! Must implement 'fooMethod'
  return class extends FooCtor {
  }
}

in such a way that Foo is declared as any other object type like an interface.

Actually, the example above isn't the problem, as FooCtor isn't generic, so you can return a non-abstract class:

function extendFoo(FooCtor: abstract new () => Foo) {
  // No error
  return class extends FooCtor {
    fooMethod(): void {} // implements it just fine.
  }
}

While this isn't necessarily sound, it aligns with other inconsistencies in the language, in that we assume Foo is the only instance type we'll create (even if you could pass an assignment compatible definition with more abstract methods). The important bit we discussed in the design meeting in November was in regards to a generic abstract constructor type. When an abstract constructor type comes from the constraint of a generic, we cannot know all of the possible permutations of that generic, therefore we must ensure the result is still marked abstract. That flows through how we handle mixins in the language, such that abstract methods in the base must eventually be implemented:

interface Foo {
  normalMethod(): void;
}
declare function FooMixin<Ctor extends abstract new(...args: any[]) => any>(base: Ctor): Ctor & (abstract new (...args: any[]) => Foo);

class Concrete {}
class SubConcrete extends MixinFoo(Concrete) {} // ok

abstract class Abstract {
  abstract fooMethod(): void;
}
class SubConcreteAbstract extends FooMixin(Abstract) {
  // I must implement 'fooMethod' because it's marked 'abstract' in the base class.
  fooMethod(): void {}
}

[rbuckton]

[...] Would interfaces themselves need to be declared abstract? [...]

No. We declare a class as abstract because it affects the constructor side. If we had abstract methods on interfaces, you might say the following are essentially the same:

// as a class
abstract class Foo {
  abstract fooMethod(): void;
}

// as an interface/constructor
interface Foo {
  abstract fooMethod(): void;
}
let Foo: abstract new () => Foo;

I would imagine that if we did introduce abstract in an interface method, we'd probably want to make new () => Foo an error since you cannot create an instance of an object with abstract methods, in the same way that class Foo { abstract fooMethod(): void; } is an error today.

[rbuckton]

I'll be pushing up a minor change to declaration emit/quick info shortly to handle inferred return types that result in an anonymous type with abstract construct signatures.

For reference, in this case:

// @target: esnext
// @declaration: true

interface Mixin {
    mixinMethod(): void;
}

function Mixin<TBase extends abstract new (...args: any[]) => any>(baseClass: TBase) {
    // must be `abstract` because we cannot know *all* of the possible abstract members that need to be
    // implemented for this to be concrete.
    abstract class MixinClass extends baseClass implements Mixin {
        mixinMethod(): void {}
        static staticMixinMethod(): void {}
    }
    return MixinClass;
}

We currently emit this:

declare function Mixin<TBase extends abstract new (...args: any[]) => any>(baseClass: TBase): {
    new (...args: any[]): { // does not preserve `abstract`
      [x: string]: any;
      mixinMethod(): void;
    };
    staticMixinMethod(): void;
}) & TBase;

When we need to emit this instead:

declare function Mixin<TBase extends abstract new (...args: any[]) => any>(baseClass: TBase): ((abstract new (...args: any[]) => {
    [x: string]: any;
    mixinMethod(): void;
}) & {
    staticMixinMethod(): void;
}) & TBase;

[rbuckton]

@RyanCavanaugh can you take one more look with the update for declaration emit?

[ITenthusiasm]

Sorry to ask, but has this already been released? abstract doesn't seem to be a recognized keyword in my repository.

[MicahZoltu]

This also updates the definitions for InstanceType and ConstructorParameters to use the abstract modifier

This doesn't appear to actually be present? There is no mention of ConstructorParameters in the PR diff, and both InstanceType and ConstructorParameters don't support abstract classes in the latest version of TS. You can build a custom ConstructorParameters, suggesting that this has been released.

[rbuckton]

This also updates the definitions for InstanceType and ConstructorParameters to use the abstract modifier

This doesn't appear to actually be present? There is no mention of ConstructorParameters in the PR diff, and both InstanceType and ConstructorParameters don't support abstract classes in the latest version of TS. You can build a custom ConstructorParameters, suggesting that this has been released.

They couldn't be added at the same time due to a lag between TS releases and the TypeScript ESLint plugin. They will be added by #43380.

[jcalz]

I was a little surprised that you can't write { abstract new(): Foo } as a synonym for abstract new() => Foo. Not sure if that's documented anywhere, but I figured I'd mention it.

[rbuckton]

It's hinted at a bit here: #36392 (comment), but was something we discussed in a Design Meeting. Adding abstract signatures to an interface (and possibly abstract members as well) was something we didn't want to touch on yet with this feature, as it introduces significantly more complexity. The intent was for the typeof class type to handle this, eventually.

[ntucker]

The declaration emit seems to not enforce abstract members...

from

type Constructor = abstract new (...args: any[]) => {};

function mixin<TBase extends Constructor>(Base: TBase) {
  abstract class MyClass extends Base {
    abstract abs(): void;
  }
  return MyClass;
}

I get

type Constructor = abstract new (...args: any[]) => {};
declare function mixin<TBase extends Constructor>(Base: TBase): (abstract new (...args: any[]) => {
    abs(): void;
}) & TBase;

But if I use that as an ambient declaration (imagine publishing a package based on this). Then an implementation lacking abs doesn't error:

class Broken extends mixin(class {}) {
  field = 5;
}

Playground (this obviously errors as it's not using ambient)

[lorenzodallavecchia]

I have noticed that abstract constructor types do not accept a class with a protected constructor.
See this playground.

Argument of type 'typeof A2' is not assignable to parameter of type 'abstract new (...args: any[]) => object'.
Cannot assign a 'protected' constructor type to a 'public' constructor type.(2345)

What is the reason for this behavior?
Abstract constructors cannot be called anyway, so their visibility should not matter IMO.