In TypeScript, what return type is inferred for `async function loadCount() { return 1; }`, and what happens if you annotate that function's return type as `number`?

## What `async` does to the signature Marking a function `async` changes its type, not just its body. The declared or inferred return type of an async function is always a promise: the compiler takes the union of the return expressions' types, unwraps any promise among them, and wraps the result once. ```ts async function loadCount() { return 1; } // inferred: () => Promise<number> ``` So the value you `return` inside the body is the *resolved* type, and the function's own type sits one level higher. This is the most common confusion in the area: people read the body, see `return 1`, and write `: number`. ## Why `: number` is rejected TypeScript refuses a non-promise annotation on an async function outright. The message says the return type of an async function or method must be the global `Promise<T>` type, and it suggests the promise form. This is a rule about `async` itself, not an ordinary assignability complaint — it fires before any question of whether the body matches. ```ts async function loadCount(): Promise<number> { // correct return 1; } ``` The annotation needs the global `Promise` type to be in scope, which is what your `lib` setting provides. In an environment whose library files do not declare it, the same annotation fails for a different reason: the type is simply not there. ## Promises do not nest The second half of the rule matters more in real code: ```ts async function fetchCount(): Promise<number> { return Promise.resolve(1); // still Promise<number> } ``` Returning a promise from an async function does not produce `Promise<Promise<number>>`. At runtime, resolving a promise with another promise adopts its state; the type system models the same flattening. This is why `return someAsyncCall()` and `return await someAsyncCall()` have the same declared type — the difference between them concerns error handling and stack behaviour at runtime, which is the JavaScript side of the fence, not the annotation. The same flattening governs `await`: awaiting a `Promise<number>` gives `number`, and awaiting a plain `number` also gives `number`. ## The everyday cases ```ts async function save(row: { id: string }): Promise<void> { await write(row); // no value returned } async function findUser(id: string): Promise<User | null> { const row = await get(id); return row ?? null; } ``` - No returned value gives `Promise<void>`. - A body with several returns unions the resolved types and wraps once: `Promise<User | null>`. - A body that only ever throws still has a promise type; the rejection is not represented in the type system at all, which is the important limitation below. ## What the annotation does *not* say The promise type has one type parameter, and it is the *resolved* type. There is no place in the signature to declare what a rejection carries. `Promise<number>` tells you nothing about failure modes, and a `catch` clause's variable is `any` — or `unknown` when `useUnknownInCatchVariables` is enabled, which `strict` turns on. If failure modes are part of your contract, they must be modelled in the resolved type itself, for example as a discriminated result object rather than as a thrown error. That is also the honest answer to "does the annotation make the function safe?": it constrains the success path and says nothing about the failure path. ## Non-async functions returning promises A function need not be `async` to return a promise, and the promise-only annotation rule does not apply to it: ```ts function loadCount(): Promise<number> { return Promise.resolve(1); // no async keyword, ordinary return-type checking } ``` From a caller's point of view the two versions of `loadCount` are indistinguishable — same type, same usage. `async` is an implementation choice that lets you use `await` inside; it is not part of the contract. That is worth saying out loud in an interview, because it explains why you can make a function `async` later without changing its declared type, as long as the resolved type stays the same. ## Erasure, once more The `Promise<number>` annotation is erased at compile time. Nothing verifies at runtime that the resolved value is a number — if the body came from `JSON.parse`, the promise resolves happily with whatever arrived. The annotation constrains what the compiler lets the body return and what callers may assume; validating untrusted data is a separate job the type layer never does for you.