You've already seen how Swift functions use named parameters to make calls self-explanatory. For example, a function that rolls a dice a certain number of times:
func rollDice(sides: Int, count: Int) -> [Int] {
var rolls = [Int]()
for _ in 1...count {
let roll = Int.random(in: 1...sides)
rolls.append(roll)
}
return rolls
}
let rolls = rollDice(sides: 6, count: 4)
Even months later, rollDice(sides: 6, count: 4) reads clearly — six sided dice, rolled four times.
🧩 Swift Uses Parameter Names to Tell Functions Apart
Parameter names are so important in Swift that they're actually used to figure out which function to call. This is valid Swift:
func recruitNinja(name: String) { }
func recruitNinja(village: String) { }
func recruitNinja(rank: String) { }
Three functions, all called recruitNinja(), but Swift knows exactly which one you mean based on the parameter name. In documentation you'll often see these written as recruitNinja(name:), recruitNinja(village:), and so on.
🙈 Removing a Parameter Label Entirely
Think about hasPrefix():
let lyric = "I am the hidden leaf village's number one knucklehead ninja"
print(lyric.hasPrefix("I am"))
We pass the prefix directly — not hasPrefix(string:) or hasPrefix(prefix:). That's because Swift lets us give a parameter two names: one for the call site, and one for use inside the function. hasPrefix() uses _ as its external name, which means "no label here at all."
We can do the same thing ourselves. Take this function:
func isUppercase(string: String) -> Bool {
string == string.uppercased()
}
let string = "BELIEVE IT!"
let result = isUppercase(string: string)
string: string reads a bit repetitive — what else would you pass in? Adding an underscore removes the external label:
func isUppercase(_ string: String) -> Bool {
string == string.uppercased()
}
let string = "BELIEVE IT!"
let result = isUppercase(string)
This is used a lot in Swift — append() for adding to an array, or contains() for checking membership — because the parameter is obvious without a label.
✍️ Giving a Parameter Two Different Names
Sometimes you want an external label, but the obvious one doesn't read naturally. Take this function:
func printTimesTables(number: Int) {
for i in 1...12 {
print("\(i) x \(number) is \(i * number)")
}
}
printTimesTables(number: 5)
printTimesTables(number: 5) is valid, but it doesn't read naturally. printTimesTables(for: 5) would read much better — you could say "print times table for 5" out loud. The problem is for is a reserved word and can't be used as a parameter name inside the function.
The solution — write two names, one external, one internal:
func printTimesTables(for number: Int) {
for i in 1...12 {
print("\(i) x \(number) is \(i * number)")
}
}
printTimesTables(for: 5)
Breaking that down:
-
for number: Int—foris the external name,numberis the internal name, and the type isInt - At the call site, we use the external name:
printTimesTables(for: 5) - Inside the function, we use the internal name:
print("\(i) x \(number) is \(i * number)")
So Swift gives us two tools: _ to remove an external name entirely, or a second name to have different external and internal labels.
💡 Terminology tip: values you pass into a function are technically called arguments, and the names you use inside the function are parameters. When the distinction matters, we call them the "external parameter name" and "internal parameter name".
When Should You Omit a Parameter Label? 🤔
Using _ for a parameter's external label is common, especially when the function name is a verb and the first parameter is the noun it acts on:
- Summoning a creature would be
summon(toad)rather thansummon(creature: toad) - Equipping a weapon would be
equip(kunai)rather thanequip(item: kunai) - Finding a target would be
find(target)rather thanfind(enemy: target)
This is especially useful when the label would just repeat the variable name being passed in:
- Casting a jutsu would be
cast(jutsu)rather thancast(jutsu: jutsu) - Activating a sharingan would be
activate(sharingan)rather thanactivate(sharingan: sharingan) - Reading a scroll would be
read(scroll)rather thanread(scroll: scroll)
💡 Before SwiftUI, apps were built with UIKit, AppKit, and WatchKit — frameworks designed around an older language called Objective-C, where a function's first parameter was always unnamed. That's why you'll often see Swift functions from those frameworks with
_for their first parameter — it keeps things compatible with Objective-C.
Why Does Swift Use Parameter Labels Anyway? 🤷
Many languages don't use parameter labels at all, or make them optional. Swift is unusual — it leans into them heavily, and even lets us split external and internal names!
Consider this kind of code, common in other languages:
setReactorStatus(true, true, false)
Perfectly normal elsewhere, but rare in Swift — because without labels, who can tell what each true or false actually means? Instead, Swift encourages this:
func setReactorStatus(primaryActive: Bool, backupActive: Bool, isEmergency: Bool) {
// code here
}
setReactorStatus(primaryActive: true, backupActive: true, isEmergency: false)
Now it's obvious what each value controls — no need to memorize argument order.
Swift takes this further by allowing two labels per parameter — one internal, one external:
func setAge(for person: String, to value: Int) {
print("\(person) is now \(value)")
}
setAge(for: "Itachi", to: 21)
This solves two problems at once:
-
At the call site,
setAge(for: "Itachi", to: 21)reads like a sentence — "set age for Itachi to 21" -
Inside the function,
personandvalueare meaningful names to work with
Compare the alternatives:
- Using only
personandvalueas labels would forcesetAge(person: "Itachi", value: 21)— "set age person Itachi value 21" isn't natural English - Using only
forandtoas labels would make the function body readprint("\(for) is now \(to)")— and Swift wouldn't even allow this, because it would thinkforwas starting a loop!
Having both internal and external names lets functions read naturally in both places. They're optional — plenty of functions only need one label — but they're a powerful tool when a function needs to read well on both sides. 🍃
Default Parameters 🎯
Default parameters let us provide sensible fallback values, so callers can ignore parameters entirely when the defaults are fine — but still customize them when needed.
Imagine a function for planning a route between two locations:
func findDirections(from: String, to: String, route: String = "fastest", avoidHighways: Bool = false) {
// code here
}
Most people want the fastest route without avoiding highways — so those become the defaults. This means the same function can be called in multiple ways:
findDirections(from: "Konoha", to: "Suna")
findDirections(from: "Konoha", to: "Suna", route: "scenic")
findDirections(from: "Konoha", to: "Suna", route: "scenic", avoidHighways: true)
Shorter code most of the time, with full flexibility when something custom is needed. 🗺️
Variadic Functions 📦
Variadic parameters let a function accept any number of values of the same type, separated by commas. Inside the function, they arrive as an array that you can loop over, index into, and so on.
The real power is that a variadic parameter can be used exactly like a normal one most of the time. Imagine an open() function for opening files:
open("photo.jpg")
If open()'s parameter is variadic, the exact same function could also open multiple files at once:
open("photo.jpg", "recipes.txt", "myCode.swift")
Nothing about how the function is called needs to change for the single-file case — variadics just unlock extra functionality on top.
You probably won't reach for variadic functions much while learning, since early projects tend to be small and specific. But as your skills grow, you'll find you can turn existing functions variadic without breaking anything that already calls them — adding new functionality without disturbing what's already there. 🌱
Wrap Up 🎬
- Parameter names aren't just documentation — Swift uses them to tell overloaded functions apart
- Use
_before a parameter name to remove its external label entirely — common when a verb function acts directly on a noun, likesummon(toad) - Give a parameter two names (
for number: Int) when you want a label that reads naturally at the call site but can't be used as an internal variable name - Default parameter values (
route: String = "fastest") let callers skip parameters they don't care about, while still allowing full customization - Variadic parameters (
numbers: Int...) let a function accept any number of values of the same type, arriving inside as an array — and can often be added later without breaking existing calls