Default & Named Arguments — Use default arguments and named arguments

Historical Context & Motivation

The concept of default arguments and named arguments in function calls did not emerge spontaneously; it evolved through decades of programming language design. Early languages like Fortran and C required every argument to be supplied in a strict positional order, which made function calls brittle and error-prone as parameter lists grew. The S language, developed at Bell Laboratories in the 1970s by John Chambers, introduced a more expressive argument-passing system that allowed programmers to assign sensible defaults and reference parameters by name. R inherited and refined this system when Ross Ihaka and Robert Gentleman created it in the early 1990s at the University of Auckland, drawing heavily on S's semantics while targeting the open-source community. Understanding this lineage helps explain why R's argument-handling conventions feel markedly different from those in C-family languages.

The central question this lesson addresses is straightforward yet consequential: when a function can accept many parameters, how do you design its interface so that callers supply only the information they truly need to customize, while safe and sensible behavior is guaranteed for everything else? R's answer—default arguments combined with named argument passing—is both elegant and occasionally surprising, especially regarding lazy evaluation and partial matching.

Core Principles & Definitions

Before diving into code, it is essential to establish the foundational vocabulary and rules that govern how R resolves arguments during a function call. R uses a three-phase matching algorithm: first it matches arguments by exact name, then by partial name, and finally by position. Default values provide a fallback for any formal parameter that remains unmatched after all three phases. These principles interact to produce R's characteristically flexible calling conventions.

Visual Explanation — Argument Matching Flow

The following diagram illustrates R's three-phase argument matching algorithm. When a function is called, R first extracts all named arguments from the call and attempts exact matches against the formal parameter list. Any remaining named arguments are then checked for unique partial matches. Finally, the remaining unnamed (positional) arguments are assigned left-to-right to whichever formals are still unbound. Any formals that remain unmatched after all three phases take their default values; if no default exists, R raises an error.

Notice that named arguments always take precedence over positional ones. This means you can freely intermix named and positional arguments: f(10, method = "lm") is perfectly valid even though the positional argument 10 appears before the named one. R removes method from the formal list during Phase 1, then assigns 10 to whichever formal is left first. This design choice is what makes named arguments so powerful in R: they decouple the caller's expression from the implementer's parameter ordering.

How It Works — Lazy Evaluation & Scope

One of the most distinctive aspects of R's default arguments is lazy evaluation. In languages like Python, default values are evaluated once at function definition time, which famously leads to the mutable-default-argument trap. R takes a fundamentally different approach: default expressions are stored as unevaluated promises and are evaluated inside the function's execution environment only when the parameter is first accessed. This means a default can reference other parameters, local computations, or even the result of calling missing() to detect whether the caller explicitly provided a value.

Default Expressions as Promises

Consider the function definition g <- function(x, n = length(x)) { ... }. The default for n is the expression length(x), not a fixed number. When a caller writes g(c(1, 2, 3)), R does not evaluate length(x) until the body of g actually uses n. At that point, x is already bound to c(1, 2, 3), so n evaluates to 3. This pattern is pervasive in R's standard library—functions like seq(), sample(), and cut() all use defaults that depend on other arguments.

The missing() Function

R provides missing(arg) to test whether a formal argument was supplied by the caller or left to its default. This is particularly useful when you need different control-flow paths depending on whether the user explicitly set a parameter. For example, function(data, col = NULL) { if (missing(col)) col <- detect_id_column(data); ... } distinguishes between a caller who passed col = NULL intentionally and one who simply omitted col.

Formal Representation

Common Patterns & Best Practices

Understanding the mechanics of default and named arguments is one thing; deploying them effectively in real codebases is another. This section catalogs the most important design patterns and anti-patterns, illustrated with a detailed diagram comparing idiomatic and problematic function calls.

The match.arg() Idiom

When a parameter should accept only a fixed set of strings, the idiomatic R approach is to list all valid options as a character vector in the default and then call match.arg() inside the function body. For example, function(method = c("pearson", "kendall", "spearman")) { method <- match.arg(method) } allows the caller to pass method = "k" (partial match) and receive "kendall". If no argument is supplied, the first element of the default vector is selected automatically. This pattern is used extensively in base R's cor(), aggregate(), and many other functions.

The Dots (...) Mechanism

R's dots argument (...) captures all unmatched named and positional arguments and forwards them to inner function calls. This complements default and named arguments by providing a clean pass-through mechanism. A wrapper function can declare its own parameters with sensible defaults and delegate everything else via dots. Note, however, that dots-based forwarding defeats partial matching for forwarded arguments and can silently swallow typos, so it should be used judiciously.

Worked Example — Building a Flexible Summarizer

Let us construct a function summarize_vec() that computes summary statistics for a numeric vector. We will design its interface using default and named arguments, demonstrating dependent defaults, the NULL sentinel pattern, and match.arg().

Strengths, Limitations & Comparisons

R's argument system is powerful, but it comes with trade-offs that differ from those in other popular languages. The table below contrasts R's approach with Python's and Java's, highlighting the design decisions that make R uniquely flexible—and occasionally treacherous.

Connection to Advanced Topics

Default and named arguments are foundational mechanisms that underpin several advanced R programming topics. Understanding them deeply prepares you for non-standard evaluation (NSE), closures and function factories, and S4 method dispatch. The table below maps each foundational concept to its advanced extension.

As you progress through an R programming course, you will find that nearly every advanced feature—from writing package APIs to building Shiny applications—depends on a solid understanding of how R evaluates and resolves function arguments. The flexibility baked into defaults and named arguments is both R's greatest ergonomic advantage and the source of its most confusing edge cases. Mastering these fundamentals now will pay dividends in every subsequent topic.

Practice Problems

Summary