Functions in TypeScript

Functions are where the types in the TypeScript for Beginners series finally earn their keep: they are the boundaries where data enters and leaves your logic. This chapter covers annotated parameters and return values, what strict mode demands of untyped parameters, optional, default and rest parameters, the void return type, function types for properties and callbacks, and overloads for functions that accept more than one shape.

Parameters and return types

Every parameter needs a type, because nothing else can infer it — the compiler reads declarations, not future call sites. The return type follows a second colon:

function add(a: number, b: number): number {
  return a + b;
}
const sum = add(2, 3);
add("2", 3);

Expected output:

error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

The return annotation is optional — const value = double(21) below infers number from the return statement — but writing it explicitly on public functions turns the signature into a promise that a careless edit inside the body cannot quietly break:

function double(n: number): number {
  return n * 2;
}
const value = double(21);   // inferred: number

Expected output: console.log(value) prints 42. Annotate the contract; let inference handle the interior.

Strict mode: no implicit any

The JavaScript style of leaving parameters bare does not survive strict, which you enabled in chapter 2:

function add(a, b) {
  return a + b;
}

Expected output:

error TS7006: Parameter 'a' implicitly has an 'any' type.

That message is a feature, not paperwork. An implicit any is a hole in your typing: every value would be accepted and every result would be untracked, which is precisely the dynamic typing TypeScript was installed to replace. Fix it by annotating the parameters. Reaching for : any is allowed, but treat it as a loan against future debugging — if the shape is genuinely unknown, unknown plus a guard is the honest annotation.

Optional, default and rest parameters

All three JavaScript tricks work, each with a typing twist. A parameter with an initializer becomes optional at the call site, and its type is inferred from the default:

function greet(name: string, greeting = "Hello"): string {
  return `${greeting}, ${name}!`;
}

console.log(greet("Ada"));
console.log(greet("Ada", "Welcome back"));

Expected output:

Hello, Ada!
Welcome back, Ada!

The default applies only when the argument is undefined — it is not a catch-all for every missing or empty value. An explicit ? marks a parameter as truly optional with no fallback, and its type inside the function includes undefined:

function tag(text: string, prefix?: string): string {
  return prefix === undefined ? text : `${prefix}:${text}`;
}

function broken(message?: string, level: string) {}

Expected output:

error TS1016: A required parameter cannot follow an optional parameter.

A required parameter may never follow an optional one, so reorder them or give the second one a default: an initialized parameter counts as optional from the caller's side, which makes level = "info" resolve the conflict. Finally, a rest parameter collects any number of trailing arguments into a typed array:

function join(separator: string, ...parts: string[]): string {
  return parts.join(separator);
}

console.log(join("-", "a", "b", "c"));

Expected output: a-b-c. ...parts must be last in the list, and because it is an array, everything from length to .map() type-checks as usual.

void: functions that return nothing

A function with no return statement hands back undefined; declaring : void tells callers not to use the result at all:

function announce(message: string): void {
  console.log(message);
}

const returned = announce("hello");
returned.toFixed(2);

Expected output:

error TS2339: Property 'toFixed' does not exist on type 'void'.

Keep three related ideas separate: void means “no usable value is returned”, undefined is the actual value a bare return; produces, and never marks a function that does not return at all — one that always throws, such as function fail(msg: string): never { throw new Error(msg); }. One asymmetry worth memorising: a function that does return a value is still allowed where a void callback is expected, with the result simply discarded. That is what lets you pass any handler to an API that promises not to use its return.

Function types and callbacks

A whole function can be typed. In a type position the arrow => separates parameters from the return type — note it is an arrow, not the colon used in object members:

type MathFn = (n: number) => number;

const negate: MathFn = (n) => -n;

function apply(nums: number[], fn: (n: number) => number): number[] {
  return nums.map((n) => fn(n));
}

console.log(apply([1, -2, 3], negate));

Expected output:

[ -1, 2, 3 ]

Two quiet powers are at work. Inside apply, n needs no annotation: the parameter's type gives the callback a context from which the compiler infers every arrow argument you pass. And the same syntax describes function-shaped members of an object type — the pattern every event handler in a UI uses:

interface Button {
  label: string;
  onClick: () => void;
}

Callbacks in TypeScript are simply functions typed as values, exactly as you have passed them in the JavaScript functions chapter — the annotations just make the contract explicit, so a callback that forgets to handle a parameter is caught at the call site rather than in production.

Overloads: more than one signature

Sometimes a function legitimately accepts different shapes and returns something different for each. Overloads list the public signatures first, then a single implementation wide enough for all of them:

function slugify(words: string): string;
function slugify(words: string[]): string;
function slugify(input: string | string[]): string {
  const text = Array.isArray(input) ? input.join(" ") : input;
  return text.toLowerCase().replace(/\s+/g, "-");
}

console.log(slugify("Hello World"));
console.log(slugify(["Hello", "World"]));

Expected output:

hello-world
hello-world

Callers see only the two overload lines; the implementation signature is hidden from them, and a call that fits neither — slugify(42) — is refused with No overload matches this call. Keep overloads few and precise: for most variation, a union parameter plus narrowing (coming up in chapter 7) is simpler to read and easier to extend.

Common mistakes

• Leaving parameters untyped — under strict every one of them raises TS7006; annotate the signature, not the body.
• Annotating the inside instead of the contract — locals are inferred; it is the parameters and return type that callers depend on.
• Expecting a default to catch null or empty values — initializers apply only when the argument is undefined.
• Declaring a return type with missing paths — : number with an early return and no final one raises error TS2366: Function lacks ending return statement and return type does not include 'undefined'.
• Typing a standalone arrow with no context — const fn = (x) => x * 2 has nothing to infer x from; annotate it as (x: number).

Practice checklist

1. Write add with full annotations, call it wrongly, and read the TS2345 message.
2. Remove the parameter types from a function, trigger TS7006, then restore them.
3. Build greet with a default and tag with ?; call each with and without the optional argument.
4. Add a second rest parameter and read the error, then combine everything into one ...parts tail.
5. Convert one callback-taking function to use a named type, pass an inline arrow, and hover to see the inference at work.

What's next?

Typed functions give you the boundaries — next you learn the types that describe values with more than one possibility in Union and Intersection Types.