In TypeScript, why does passing an abstract class to a parameter typed `new () => Shape` fail to compile, and how do you type the parameter so it accepts one?

## The rule the compiler is protecting `abstract class Shape { abstract area(): number; }` cannot be instantiated: `new Shape()` is an error, because the class has members with no implementation. A plain construct signature `new () => Shape` is exactly the licence to write `new ctor()`. If the compiler let you pass `Shape` there, the callee would be free to construct an object whose `area` does not exist — so the assignment is blocked at the boundary rather than at the call. The error names the two type kinds explicitly: "Cannot assign an abstract constructor type to a non-abstract constructor type." ## Abstract construct signatures TypeScript can describe the constructor of an abstract class with the `abstract` modifier on the signature itself: ```ts abstract class Shape { abstract area(): number; } class Unit extends Shape { area(): number { return 1; } } let ctor: abstract new () => Shape; ctor = Shape; // ok ctor = Unit; // ok — concrete constructors are assignable to the abstract form ``` The direction of assignability is the useful part: `abstract new () => T` is the *wider* type, accepting both kinds; `new () => T` is the narrower one, accepting only concrete classes. Choosing between them is therefore a statement about what your function does with the value: - **You call `new`** — use `new () => Shape`, and accept that abstract classes are correctly rejected. - **You never call `new`** — use `abstract new () => Shape` so callers may hand you a base class. A value typed `abstract new () => Shape` cannot be instantiated inside the function. That restriction is the whole point; if you find yourself asserting it back to a concrete signature with `as`, the parameter type was the wrong choice. ## What you do with a non-constructable constructor Plenty of useful code holds a class without building one: registries keyed by class, `instanceof` dispatch tables, metadata lookups, and — most commonly — anything that only means to `extends` the value. A base class you intend to derive from does not need to be concrete, and requiring it to be would be an artificial restriction. ```ts abstract class Shape { abstract area(): number; } function describe(list: Shape[], base: abstract new () => Shape): number { // no `new base()` here — only identity and instance checks return list.filter((s) => s instanceof (base as Function as new () => Shape)).length; } ``` That assertion in the last line is deliberately ugly; usually you would simply keep a concrete signature where you need `instanceof`, and reserve the abstract form for parameters you only pass along. ## The static side is still there Abstractness affects only constructability. The rest of the static side behaves normally: static members, `prototype`, and inherited statics are all visible through either signature form. `abstract` on a *member* is separate again — `abstract area(): number` says subclasses must supply it, and it lives on the instance side. ## Erasure, once more Nothing about this survives compilation. The emitted JavaScript for an abstract class is an ordinary class, and `new Shape()` would succeed at run time, producing an object whose `area` is simply missing. The abstract-constructor rule is a compile-time guard rail over a runtime that has no notion of abstractness at all — which is exactly why an `as` assertion around it is dangerous rather than merely noisy.