skip to content

Named Arguments

3 roadmaps5 questions

Naming arguments at the call site lets you skip defaults, reorder, and make boolean parameters readable. The constraint worth knowing is that named arguments do not work for Java methods, whose parameter names are not guaranteed to be retained.

part ofKotlinoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What are named arguments in Kotlin, and what call-site problems do they solve?

level: juniorimportance: must knowfreq 70%

answer

  1. name = value at the call site
  2. call-site only, declaration unchanged
  3. readability for booleans/ints
  4. skip defaulted params by naming later ones
  5. name must match parameter name

basics

~10 s

Named arguments let you pass a value by writing the parameter's name, like draw(width = 5). This makes calls easier to read and lets you supply only the arguments you want, in any order.

solid answer

~30 s

A named argument is supplied with the syntax name = value at the call site, matching the parameter declared in the function. They improve readability for ambiguous calls (e.g. several Boolean or Int parameters), let you reorder arguments, and let you skip parameters that have default values without listing every preceding one. For example reformat(text, normalizeCase = true) is clearer than reformat(text, true, true, false). They are a call-site-only feature: nothing changes in the function declaration. They pair naturally with default arguments, since skipping a defaulted parameter requires naming the ones you do pass.

code

kotlin · 5 lines
kotlin
fun connect(host: String, port: Int = 443, useTls: Boolean = true) {}

connect("api.example.com")                 // all defaults
connect("api.example.com", useTls = false) // skip port, name the later one
connect(port = 8080, host = "localhost")   // reordered

go deeper

for a junior

Can state the name = value syntax and that it improves readability and lets you skip defaulted parameters.

for a middle

Explains the reorder/skip mechanics and that renaming a parameter breaks named callers.

for a senior

Frames named args as a call-site contract, ties them to default arguments and API ergonomics/evolution.

for a principal

Discusses parameter names as public API surface and stability implications across a codebase or library.

## What a named argument is In Kotlin you can pass an argument to a function by writing the **parameter name** followed by `=` and the value, instead of relying on position. This is a **call-site** feature — the function declaration is unchanged. ```kotlin fun reformat( text: String, normalizeCase: Boolean = true, upperCaseFirstLetter: Boolean = true, divideByCamelHumps: Boolean = false, wordSeparator: Char = ' ', ) { /* ... */ } // positional — what do these booleans mean? reformat("hello", true, true, false, '_') // named — self-documenting reformat("hello", normalizeCase = true, wordSeparator = '_') ``` ## Problems they solve - **Readability**: long parameter lists, especially with several `Boolean`/`Int`/`Char` values, are hard to read positionally. Names make each value's meaning explicit at the call site. - **Skipping defaults**: when a parameter has a **default value**, you can omit it. But to skip one in the *middle* and still pass a later one, you must name the later argument — otherwise position would be ambiguous. - **Reordering**: once you start using names, you can list arguments in any order you like. ## Key rules - The name must exactly match the **parameter name** in the declaration. Renaming a parameter is therefore a source-breaking change for callers using names. - Named arguments don't require default values — you can name every argument of any Kotlin function. - They work with regular and `vararg` parameters, with one caveat covered in advanced questions (spread vs. multiple named values). ## Quick mental model Think of named arguments as filling in a labeled form rather than handing values across a counter in a fixed order.

  • Do named arguments change anything about how the function is declared?
    No. They are purely a call-site convenience; the function signature is identical whether callers use positional or named arguments.
  • If you rename a parameter, what happens to callers using named arguments?
    Their calls break at compile time because the name no longer matches. Parameter names are part of the call-site contract.

Like filling in a labeled form instead of passing values across a counter in a fixed order.

saying these in an interview costs you the question

  • Claiming named arguments require default values to be used
  • Thinking the function declaration must be marked specially to allow named calls
  • Saying the value name can differ from the parameter name
  • Believing named arguments are a runtime feature with overhead

context

resolving links…

open as a page

What are the rules for mixing positional and named arguments in a single Kotlin call?

level: middleimportance: must knowfreq 60%

basics

~20 s

You can start a call with positional arguments and then switch to named ones, but once you use a name you generally must keep naming the rest. In modern Kotlin you may put positional arguments after named ones as long as they land in the right positions.

open as a page

How do named arguments combine with default arguments to let callers skip parameters, and what's the alternative in Java interop?

level: middleimportance: should knowfreq 55%

basics

~20 s

When a function has default values, you can leave out a middle parameter by naming the later ones you want to set. Without named arguments you'd have to repeat every value up to the last one you care about.

open as a page

Why can't you use named arguments when calling Java methods from Kotlin, and how does this interact with varargs?

level: seniorimportance: should knowfreq 45%

basics

~10 s

Java bytecode usually doesn't keep parameter names, so Kotlin can't reliably match a name to a Java method's parameter. Therefore Kotlin forbids named arguments on calls to Java methods; you must pass them positionally.

open as a page

How should named arguments influence the design and evolution of a public Kotlin API?

level: principalimportance: nice to knowfreq 30%

basics

~10 s

Because callers can pass arguments by name, parameter names become part of your public contract. Pick names carefully and avoid renaming or reordering them, since that can break callers who used names.

open as a page