How Do Default Parameters Evaluate?

A parameter with a default uses that value only when the caller does not supply one. The default expression is worked out at call time, once for each call, and only when it is really needed.

function greet(name = 'friend') {
  return 'Hello ' + name;
}

console.log(greet());
console.log(greet('Ada'));
console.log(greet(undefined));
console.log(greet(null));
console.log(greet(''));

// The default can depend on another parameter.
function withSuffix(value, suffix = 'px') {
  return value + suffix;
}

console.log(withSuffix(10));
console.log(withSuffix(10, 'em'));

The order of evaluation is left to right, and a default can refer to any parameter that was declared before it. That is the single most useful property of the feature, because it lets you build a parameter list where later values are worked out from earlier ones, without repeating the same expression inside the body of the function.

Two details are commonly misunderstood. Passing an explicit empty value does not trigger the default, because only a missing argument or an explicit empty marker does. And the default expression is not worked out at all when the caller supplies a value, so a default that calls an expensive function costs nothing on the common path.

There is one classic mistake worth mentioning. If the default refers to a parameter that comes after it, then the code is a syntax error, because the parameters are given their values in order and a later one does not exist yet at that point.

The default is ignored completely, and your value is used. The default expression is not even worked out, so it costs nothing. This is worth stating, because a common worry is that a default with a side effect, such as calling a function that increases a counter, would still run. It does not.

The more interesting question is what counts as not passing a value. Three cases fall back to the default. You leave the argument out entirely, you pass an explicit empty marker, or you pass a gap by leaving a comma in the middle of the argument list. In all three of those cases the parameter ends up in the same state, and the default kicks in.

Everything else is taken at face value. A null value stays null, a zero stays zero, an empty string stays an empty string, and a false boolean stays false. The default is not a test for a false value, it is a test for a missing argument.

That distinction is the reason to prefer defaults over the older fallback pattern. Writing function f(name) { name = name || 'friend'; } replaces an empty string and a zero with the fallback, which is usually wrong. A default parameter only fills in a genuinely missing argument, and it leaves every other value alone.

One more case is worth knowing. If a default expression itself refers to a parameter that has a default, then the chain is resolved in order, and each default is worked out at most once per call.

Because the parameters are given their values from left to right, and a default is worked out at the moment its own parameter is set up. At that point a parameter that is declared further down the list has not been given a value yet, so referring to it would mean reading a binding that does not exist. The language makes that a syntax error rather than a surprise at runtime, because it can never work.

// A default may use any parameter that was declared before it.
function scaled(size, factor = size * 2) {
  return size * factor;
}

console.log(scaled(10));

// Going the other way is rejected when the file is read:
// function broken(factor = size * 2, size) {}

// Defaults are worked out per call, left to right, and only when needed.
let calls = 0;

function nextId() {
  calls = calls + 1;
  return calls;
}

function register(id = nextId(), name = 'user' + id) {
  return { id: id, name: name };
}

console.log(register());
console.log(register(5, 'ada'));
console.log('nextId calls:', calls);

The register example shows the two rules in action. The defaults are worked out from left to right, so the second default can use the value that the first default produced. And the nextId function is only called when the caller leaves out the id, which is why the counter is still at one after the second call that supplies both arguments.

The same left-to-right rule explains the temporal dead zone inside a parameter list. If a parameter's default refers to a variable that is declared later in the function body, then that variable has not been set up yet, and reading it throws a ReferenceError. The parameter defaults are set up before the body runs, so the body is still in its dead zone at that moment.

In practice, the fix is always to reorder the parameters so that the dependency flows forward, and to remember that defaults are expressions, so they can contain calls, conditionals, and other logic.