In TypeScript, which values are assignable to the type `{}`, how does that differ from the type `object`, and why is `{}` a poor way to say "some object"?

## Why `{}` accepts a number Assignability walks the members the *target* declares. `{}` declares none. So for almost any source, the walk finishes immediately with nothing to check, and the assignment succeeds: ```ts const a: {} = 42; // ok const b: {} = "text"; // ok const c: {} = () => 1; // ok const d: {} = { any: 1 }; // ok // const e: {} = null; // error under strictNullChecks // const f: {} = undefined; // error under strictNullChecks ``` Primitives pass because TypeScript compares them through their **apparent type** — the members a `number` gets from the `Number` interface, a `string` from `String`, and so on. A primitive is not a bare scalar to the checker; it has methods, and it certainly has the zero members `{}` asks for. The only values excluded are `null` and `undefined`, which have no members at all, and only when `strictNullChecks` is on. Turn that flag off and even they are assignable, since `null` and `undefined` are then assignable to everything. So the accurate reading of `{}` is **"any non-nullish value"**, not "an empty object". ## `{}` versus `object` versus `Object` - **`{}`** — any non-nullish value, primitives included. - **`object`** (lowercase, a real keyword type) — any **non-primitive**: object literals, arrays, functions, class instances. `const n: object = 42` is an error. - **`Object`** (capital, the interface from the standard library) — declares `toString`, `valueOf`, `hasOwnProperty` and friends, which primitives also have through their apparent types, so it behaves much like `{}` in practice. Using it is generally discouraged precisely because it reads like `object` and does not behave like it. - **`unknown`** — the true top type: everything is assignable to it, `null` and `undefined` included, and nothing may be done with it before narrowing. ```ts const g: object = { a: 1 }; // ok // const h: object = 42; // error — primitives excluded const i: unknown = null; // ok — unknown admits everything ``` ## Why it is a poor "some object" Two reasons. First, it does not mean what the reader thinks. Someone writing `function f(x: {})` almost always intends "pass me an object"; the signature actually accepts `f(1)` and `f("no")`, and the mistake surfaces far from the declaration. Second, it gives you nothing to work with. There are no declared members, so `x.id` is an error, and iterating requires narrowing first — `typeof x === "object" && x !== null`, then an `in` check or a validator. If you have to narrow anyway, `unknown` is the more honest starting point: it forces the narrowing instead of quietly letting a `number` slide through. The alternatives, chosen by intent: ```ts function takesAnything(x: unknown) {} // I know nothing yet function takesSomeObject(x: object) {} // non-primitive, opaque function takesBag(x: Record<string, unknown>) {} // string-keyed, contents unknown ``` ## Where `{}` is genuinely the right tool It has one real, deliberate use: as the "non-nullish" constraint. Intersecting a type with `{}` removes `null` and `undefined` from it, which is exactly how the standard library's `NonNullable<T>` is defined in TypeScript 5.x — `T & {}`. The same trick appears in generic constraints, `T extends {}`, to say "any non-nullish type" without excluding primitives. ```ts type A = NonNullable<string | null>; // string type B = string | undefined & {}; // careful: & binds tighter than | ``` That second line is a good reminder to parenthesise: `(string | undefined) & {}` is what removes the `undefined`. ## How to answer Lead with the mechanism — a target with no required members has nothing to reject — then give the boundary (`null` and `undefined`, under `strictNullChecks`), then contrast with `object` and `unknown`, and finish with the one legitimate use as a non-nullish constraint. That order shows you derived the behaviour from the assignability rule rather than memorising a curiosity.