In TypeScript, what does the type `new (name: string) => Person` describe, and which values are actually assignable to it?

## Two kinds of invocation, two kinds of signature An object type in TypeScript can carry several sorts of member: properties, index signatures, **call signatures** (`(x: number): string`) and **construct signatures** (`new (x: number): Foo`). The two signature kinds answer different questions — a call signature says what happens when you write `f(x)`, a construct signature says what happens when you write `new f(x)`. A type may have either, both, or several of each. ```ts interface PersonCtor { new (name: string): Person; // member form } type PersonCtorAlias = new (name: string) => Person; // standalone form ``` The two forms mean the same thing. The arrow form is convenient inline in a parameter list; the member form is what you use when the type also needs properties. ## What the return type means In `new (name: string): Person`, `Person` is the **instance** type produced, not the constructor. So the signature describes the maker; the annotation after the colon describes the product. That is the split the whole topic turns on: a factory parameter is typed with the construct signature, and whatever it returns is typed with the instance type. ## Which values satisfy it Assignability is structural, but a value only matches if its own type actually *has* a construct signature: ```ts class Person { name: string; constructor(name: string) { this.name = name; } } const A: new (name: string) => Person = Person; // ok: class declaration const B: new (name: string) => Person = class extends Person {}; // ok: class expression // const C: new (name: string) => Person = (n: string) => new Person(n); // error ``` The last line fails because an arrow function's type has a call signature and no construct signature — the compiler reports that the source "provides no match for the signature 'new (name: string): Person'". This is one of the few places where the type layer models a real runtime distinction faithfully: an arrow function genuinely cannot be constructed. A plain `function` declaration is likewise typed with only a call signature, so it too is rejected even though the underlying JavaScript value would be newable. Parameters are checked the usual way, so a constructor taking fewer parameters is assignable (extra parameters may be ignored), and the produced instance type must be assignable to the declared one, which means subclasses pass. ## Mixing call and construct signatures The standard library is the best real example. `lib.es5.d.ts` declares: ```ts interface StringConstructor { new (value?: any): String; (value?: any): string; readonly prototype: String; fromCharCode(...codes: number[]): string; } declare var String: StringConstructor; ``` One interface describes a value that behaves differently with and without `new`, and also carries statics such as `fromCharCode`. That is how the global `String` gets its type, and it is the pattern you copy when you need to describe an existing library object that is callable, constructable and has properties. ## Where you actually reach for it Any code that receives a class as a value: registries, plugin systems, dependency-injection containers, test doubles, `instanceof`-based lookups. Typing the parameter `new (…) => T` gives the caller a precise contract without naming a specific class, and gives the callee the right to write `new ctor(…)`. ```ts function spawnTwo(ctor: new (name: string) => Person): Person[] { return [new ctor("a"), new ctor("b")]; } ``` If you type the parameter `Function` instead, you can still call it but the result is `any`, and you have thrown away the very thing the annotation was for. ## And none of it exists at runtime A construct signature is a compile-time description. It disappears at emit; nothing checks at run time that the value you passed is really constructable. If the value arrives from `JSON.parse`, a dynamic `import`, or an `as` assertion, the compiler's promise is only as good as whatever produced it — the guarantee is on the code paths the checker actually saw.