skip to content

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

level: middleimportance: must knowfreq 60%

answer

  1. pre-1.4: positional must precede all named
  2. 1.4+: positional after named OK if in correct position
  3. compiler binds names first, then positional in order
  4. out-of-order positional = compile error
  5. convention: positional first, named last

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.

solid answer

~40 s

Historically Kotlin required that once you used a named argument, every following argument also be named — positional arguments could not appear after a named one. Since Kotlin 1.4, this was relaxed: you may use positional arguments after named ones provided each positional argument still falls in its correct declared position. The compiler resolves names first, then fills remaining positional arguments against the remaining parameters in order; if a positional argument would land out of order it's a compile error. The safe, readable convention is: positional first, then named. Mixing is most useful when you want to set one early parameter by name (for clarity) yet keep later trailing arguments positional.

code

kotlin · 5 lines
kotlin
fun f(a: Int, b: Int, c: Int) {}

f(1, b = 2, c = 3)   // positional then named: always fine
f(a = 1, 2, 3)        // 1.4+: positional after named, still in order -> OK
// f(c = 3, 1, 2)     // ERROR: 1 would fill 'a', out of order after naming c

go deeper

for a junior

Knows the safe convention: positional first, then named, and that mixing is allowed in that direction.

for a middle

States both the classic and 1.4+ rules and the in-order constraint for positional-after-named.

for a senior

Explains the compiler's bind-names-then-fill-positional resolution and why the in-order rule prevents ambiguity.

for a principal

Advises a team style (positional first, named last) and reasons about readability/maintenance tradeoffs of relying on 1.4+ behavior.

## The classic rule (pre-1.4) For a long time Kotlin enforced: **once you name an argument, all subsequent arguments in that call must also be named.** A positional argument after a named one was a compile error. ```kotlin fun f(a: Int, b: Int, c: Int) {} f(1, c = 3, b = 2) // ok: positional then all-named // f(a = 1, 2, 3) // pre-1.4: ERROR — positional after named ``` ## The relaxed rule (Kotlin 1.4+) Since **Kotlin 1.4** you can place positional arguments after named ones **as long as each positional argument is in its correct position**. The compiler: 1. Binds the named arguments to their parameters. 2. Fills the remaining positional arguments left-to-right against the remaining parameters **in declaration order**. 3. Reports an error if a positional argument would be assigned out of its natural order. ```kotlin fun f(a: Int, b: Int, c: Int) {} f(a = 1, 2, 3) // ok in 1.4+: 2 -> b, 3 -> c (still in order) // f(b = 2, 1, 3) // ERROR: positional 1 would have to fill 'a', which is out of order ``` ## Why the in-order constraint exists Positional arguments only carry meaning by their slot. If a positional value could jump backward over a parameter you already named, the call would be ambiguous and error-prone. Kotlin keeps positional resolution strictly left-to-right over the **unfilled** parameters. ## Practical convention Even though 1.4+ allows positional-after-named, most style guides keep it simple: - **Positional arguments first, named arguments last.** - Reach for names when a value's meaning is unclear (booleans, magic numbers) or when skipping defaulted parameters. This avoids reader confusion and side-steps the in-order subtleties entirely.

  • Which Kotlin version relaxed the positional-after-named restriction?
    Kotlin 1.4 introduced support for positional arguments after named ones, provided each positional argument still lands in its correct declared position.
  • Why does f(b = 2, 1, 3) fail to compile?
    After binding b by name, the positional 1 would have to fill a, but a precedes b in declaration order, so the positional argument is out of order — which the compiler rejects.

saying these in an interview costs you the question

  • Claiming you can never mix positional and named arguments at all
  • Saying positional after named always works regardless of order
  • Not knowing the rule changed across Kotlin versions
  • Asserting the compiler reorders positional arguments to fit

context

resolving links…