Support mixins for abstract classes

Search Terms

Related to #32122, but not the same.
abstract mixins classes

Suggestion

Right now we can't to extending abstract classes with mixins. So, it would be nice to create a solution for this case.

Use Cases

abstract class Test {
}

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

function MyAwesomeMixin<T extends Constructor>(Constructor: Constructor) {
  abstract class MyAwesomeMixin extends Constructor {
  }
  return MyAwesomeMixin;
}

class A extends MyAwesomeMixin(Test) {
  /* Argument of type 'typeof Test' is not assignable to parameter of type 'Constructor'.
  Cannot assign an abstract constructor type to a non-abstract constructor type.(2345) */
}

Okay, try to create abstract constructor type:

type Constructor = abstract new (...args: any[]) => any;
/* Syntax error */

Hmm,..

Examples

Here is two way to create solution for this problem:

1. (simple) Allow create abstract constructor types

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

2. (complex, but beautiful) Add new syntax to define mixins, and initially add support to extending abstract classes, like this:

abstract class Test {
   abstract mainMethod(): void;
}

mixin MyAwesomeMixin {
   public someMethod(): void {
      console.log('hello');
   }
}

class A extends MyAwesomeMixin(Test) {
   public mainMethod(): void {
      this.someMethod();
   }
}

// AND

abstract mixin MyAwesomeAbstractMixin {
    abstract someMethod(): void;
}

class B extends MyAwesomeAbstractMixin(Test) {
   public mainMethod(): void {
      this.someMethod();
   }
}

// Also this can add support to extending mixins without Mixin(Mixin2(Mixin3(Class)))

mixin MyAwesomeExtendedMixin extends MyAwesomeAbstractMixin {
   public someMethod(): void {
      ...
   }
}

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Start with the abstract-class and mixin examples in the issue, then review related issue #32122. Compare the proposed constructor-type and mixin-syntax approaches, and determine which design supports extending abstract classes while preserving the stated TypeScript design constraints. Done means the chosen behavior is specified and the examples no longer produce the reported constructor-type error.