Functions and argument labels

The two-name idea

func greet(person name: String, from town: String) -> String {
    "Hello \(name)! Glad you could visit from \(town)."
}

greet(person: "Ada", from: "London")

person and from are what callers write. name and town are what the body uses. The point is that the two audiences want different things: the call site wants to read like English, the body wants short working names.

If you write only one name, it serves as both:

func square(number: Int) -> Int { number * number }
square(number: 4)

And _ removes the label entirely, for cases where it adds nothing:

func square(_ number: Int) -> Int { number * number }
square(4)

Single-expression functions omit return

func square(_ n: Int) -> Int { n * n }        // implicit return
func describe(_ n: Int) -> String {
    let parity = n % 2 == 0 ? "even" : "odd"
    return "\(n) is \(parity)"                 // explicit — more than one statement
}

Only bodies consisting of exactly one expression get the shortcut. Anything longer needs return.

Default values

func makeCoffee(size: String = "medium", shots: Int = 1, decaf: Bool = false) -> String {
    "\(size) coffee, \(shots) shot(s)\(decaf ? ", decaf" : "")"
}

Callers supply only what differs from the default, in the declared order:

Defaults are why Swift needs far fewer overloads than Objective-C or Java. One function with sensible defaults replaces five near-identical ones.

Variadic parameters

func total(_ numbers: Int...) -> Int {
    numbers.reduce(0, +)
}

total(1, 2, 3)     // 6
total()            // 0

Inside the function, numbers is an ordinary [Int].

Parameters are constants

This catches people out:

func addSuffix(to name: String) -> String {
    // name += "!"   ← does not compile; parameters are `let`
    var result = name
    result += "!"
    return result
}

Parameters cannot be reassigned. If you want a mutable working copy, make one. This is not busywork — imagine the mutable world: name gets trimmed and lowercased on line 2 "for convenience", and on line 14 an error message reports "could not find user \(name)" — quietly printing the mutated value, not what the caller sent, while someone debugs the wrong input for an afternoon. Parameters being let means that line can never lie: a parameter always still holds exactly what the caller passed.

inout — deliberately changing the caller's value

When a function's job is to modify what it was given, say so:

func doubleInPlace(_ value: inout Int) {
    value *= 2
}

var score = 21
doubleInPlace(&score)   // the & is required at the call site
print(score)            // 42

The & at the call site is the point. A reader can see, without opening the function, that this call may change score.

Functions are values

A function can be stored, passed, and returned like any other value. Its type is written (Int, Int) -> Int.

func add(_ a: Int, _ b: Int) -> Int { a + b }

let operation: (Int, Int) -> Int = add
print(operation(2, 3))    // 5

This is what makes map, filter and sorted possible — they take a function as an argument. The next lesson is entirely about that.

Naming, the Apple way

Swift's API Design Guidelines are unusually specific, and following them makes your code look like it belongs next to the frameworks.

• Clarity at the point of use beats brevity. The call site is read far more often than the declaration.
• Methods that do something read as verb phrases: list.sort(), view.removeFromSuperview().
• Methods that return something read as noun phrases: list.sorted(), text.uppercased().
• Mutating/non-mutating pairs use ed/ing: sort() / sorted(), reverse() / reversed().
• Do not repeat type information that is already in the signature. remove(at: Int), not removeElementAtIndex(index: Int).