Allow `abstract` modifier on construct signature in object type literal

[parzhitsky]

🔍 Search Terms

'abstract' modifier cannot appear on a type member

✅ Viability Checklist

• [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [X] This wouldn't change the runtime behavior of existing JavaScript code
• [X] This could be implemented without emitting different JS based on the types of the expressions
• [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Allow using abstract new … constructor definition keywords in an interface, i.e. in an object form (i.e., within curly braces).

📃 Motivating Example

Consider possible definitions of:

• a function (a callable object),
• a non-abstract constructor,
• an abstract constructor.

All of those definitions can be created through type aliasing:

type Callable = () => void // ✅

type Constructor = new () => void // ✅

type ConstructorAbstract = abstract new () => void // ✅

But only the first two definitions can be created using an object form:

type Callable = { (): void } // ✅

type Constructor = { new (): void } // ✅

type ConstructorAbstract = { abstract new (): void } // ❌
//                           ^^^^^^^^
// Error: 'abstract' modifier cannot appear on a type member

Try it.

Apparently, in this form the token new is considered a method name, rather than a keyword.

I suggest making the last one a valid expression by parsing new as a keyword.

💻 Use Cases

This suggestion is mainly for visual consistency, there is no functional change sought to be. To the folks who prefer using interfaces whenever possible (like me), the requirement of using type here is somewhat unreasonable, although it doesn't pose any significant problems.

[parzhitsky]

This looks more like a bug, but there is no "previous behaviour that is broken", so I'm filing it as a suggestion

[MartinJohns]

Related: #41197

[StepanMynarik]

Same problem here.

I have special type for abstract components in my game engine (that is used to constrain whether abstract components can be passed to a certain function or not).

I also have other type for normal non-abstract components.

The second one can normally have the constructor defined in it:

export interface IComponentClass<TComponent extends Component> {
  new(entity: Entity): TComponent;
  prototype: TComponent;
  etc...
};
export type ComponentClass<TComponent extends Component> = IComponentClass<TComponent>;

While the first one not, so I solve it like this (it works but it will be confusing in the future, why both are not defined the same way):

export type AbstractComponentConstructor<TComponent extends Component> = abstract new(entity: Entity) => TComponent;
export interface IAbstractComponentClass<TComponent extends Component> {
  prototype: TComponent;
}
export type AbstractComponentClass<TComponent extends Component> = AbstractComponentConstructor<TComponent>
  & IAbstractComponentClass<TComponent>;