A function is like one of those pseudoscientific machines for processing miscellaneous stuff that you probably drew in your math textbook in elementary school. You know the ones I mean: with a funnel-like “hopper” at the top, and then a bunch of gears and cranks, and then a tube at the bottom where something is produced. A function is a machine like that: you feed some stuff in, the stuff is processed in accordance with what this particular machine does, and something is produced.

The stuff that goes in is the input; what comes out is the output. More technically, a function that expects input has parameters; a function that produces output has a result. For example, here’s a very silly but perfectly valid function that expects two Int values, adds them together, and produces that sum:

func sum (_ x:Int, _ y:Int) -> Int {
    let result = x + y
    return result
}

The syntax here is very strict and well-defined, and you can’t use Swift unless you understand it perfectly. Let’s pause to appreciate it in full detail; I’ll break the first line into pieces so that I can call them out individually:

func sum                      ❶
    (_ x:Int, _ y:Int)        ❷❸
    -> Int {                  ❹❺
        let result = x + y    ❻
        return result         ❼
}

Here are some further points to note about the parameters and return type of our function:

The function declaration before the curly braces is, in short, a contract about what kinds of values will be used as input and about what kind of output will be produced. According to this contract, the function expects a certain number of parameters, each of a certain type, and yields a certain type of result. Everything must correspond to this contract. The function body, inside the curly braces, can use the parameters as local variables. The returned value must match the declared return type.

The same contract applies to code elsewhere that calls this function. Here’s some code that calls our sum function:

let z = sum(4,5)

Focus your attention on the right side of the equal sign — sum(4,5). That’s the function call. How is it constructed? It uses the name of the function; that name is followed by parentheses; and inside those parentheses, separated by a comma, are the values to be passed to each of the function’s parameters. Technically, these values are called arguments. Here, I’m using literal Int values, but I’m perfectly free to use Int variables instead; the only requirement is that I use things that have the correct type:

let x = 4
let y = 5
let z = sum(y,x)

In that code, I purposely used the names x and y for the variables whose values are passed as arguments, and I purposely reversed them in the call, to emphasize that these names have nothing to do with the names x and y inside the function parameter list and the function body. These names do not magically make their way to the function. Their values are all that matter; their values are the arguments.

What about the value returned by the function? That value is magically substituted for the function call, at the point where the function call is made. It happens that in the preceding code, the result is 9. So the last line is exactly as if I had said:

let z = 9

The programmer and the compiler both know what type of thing this function returns, so they also know where it is and isn’t legal to call this function. It’s fine to call this function as the initialization part of the declaration of the variable z, just as it would be to use 9 as the initialization part of that declaration: in both cases, we have an Int, and so z ends up being declared as an Int. But it would not be legal to write this:

let z = sum(4,5) + "howdy" // compile error

Because sum returns an Int, that’s the same as trying to add an Int to a String — and by default, you can’t do that in Swift.

Observe that it is legal to ignore the value returned from a function call:

sum(4,5)

That code is sort of silly in this particular situation, because we have made our sum function go to all the trouble of adding 4 and 5 for us and we have then thrown away the answer without capturing or using it. The compiler knows this, and will warn that we are failing to use the result of our function call. Nevertheless, a warning is not an error; that code is legal. There are, in fact, lots of situations where it is perfectly reasonable to ignore the value returned from a function call; in particular, the function may do other things (technically called side effects) in addition to returning a value, and the purpose of your call to that function may be those other things.

If you can call sum wherever you can use an Int, and if the parameters of sum have to be Int values, doesn’t that mean you can call sum inside a call to sum? Of course it does! This is perfectly legal (and reasonable):

let z = sum(4,sum(5,6))

The only argument against writing code like that is that you might confuse yourself and that it might make things harder to debug later. But, technically, it’s legal, and quite normal.

func greet1() -> Void { print("howdy") }
func greet2() -> () { print("howdy") }
func greet3() { print("howdy") }

greet1()

(Int, Int) -> Int

A function can externalize the names of its parameters. The external names must then appear in a call to the function as labels to the arguments. There are several reasons why this is a good thing:

Externalized parameter names are so standard in Swift that there’s a rule: by default, all parameter names are externalized automatically, using the internal name as the externalized name. Thus, if you want a parameter name to be externalized, and if you want the externalized name to be the same as the internal name, do nothing — that will happen all by itself.

If you want to depart from the default behavior, you can do either of the following in your function declaration:

Here’s the declaration for a function that concatenates a string with itself a given number of times:

func echoString(_ s:String, times:Int) -> String {
    var result = ""
    for _ in 1...times { result += s }
    return result
}

That function’s first parameter has an internal name only, but its second parameter has an external name, which will be the same as its internal name, namely times. And here’s how to call it:

let s = echoString("hi", times:3)

In the call, as you can see, the external name precedes the argument as a label, separated by a colon.

Now let’s say that in our echoString function we prefer to use times purely as an external name for the second parameter, with a different name — say, n — as the internal name. And let’s strip the string off the function’s name (before the parentheses) and make it the external name of the first parameter. Then the declaration would look like this:

func echo(string s:String, times n:Int) -> String {
    var result = ""
    for _ in 1...n { result += s}
    return result
}

In the body of that function, there is now no times variable available; times is purely an external name, for use in the call. The internal name is n, and that’s the name the code refers to. And here’s how to call it:

let s = echo(string:"hi", times:3)

In Swift, function overloading is legal (and common). This means that two functions with exactly the same name, including their external parameter names, can coexist as long as they have different signatures.

Thus, for example, these two functions can coexist:

func say (_ what:String) {
}
func say (_ what:Int) {
}

The reason overloading works is that Swift has strict typing. A String is not an Int. Swift can tell them apart in the declaration, and Swift can tell them apart in a function call. Thus, Swift knows unambiguously that say("what") is different from say(1).

Overloading works for the return type as well. Two functions with the same name and parameter types can have different return types. But the context of the call must disambiguate; that is, it must be clear what return type the caller is expecting.

For example, these two functions can coexist:

func say() -> String {
    return "one"
}
func say() -> Int {
    return 1
}

But now you can’t call say like this:

let result = say() // compile error

The call is ambiguous, and the compiler tells you so. The call must be used in a context where the expected return type is clear. For example, suppose we have another function that is not overloaded, and that expects a String parameter:

func giveMeAString(_ s:String) {
    print("thanks!")
}

Then giveMeAString(say()) is legal, because only a String can go in this spot, so we must be calling the say that returns a String. Similarly:

let result = say() + "two"

Only a String can be “added” to a String, so this must be the say() that returns a String.

The legality of overloading in Swift is particularly striking if you’re coming from Objective-C, where overloading is not legal. If you tried to declare two overloaded versions of the same method in Objective-C, you’d get a “Duplicate declaration” compile error. And indeed, if you try to declare two overloaded methods in Swift, but in a place where Objective-C can see them (see Appendix A. C, Objective-C, and Swift for what that means), you’ll get a Swift compile error, because such overloading is incompatible with Objective-C.

A parameter can have a default value. This means that the caller can omit the parameter entirely, supplying no argument for it; the value will then be the default.

To specify a default value in a function declaration, append = and the default value after the parameter type:

class Dog {
    func say(_ s:String, times:Int = 1) {
        for _ in 1...times {
            print(s)
        }
    }
}

In effect, there are now two functions — say(_:) and say(_:times:). If you just want to say something once, you can call say(_:) with a single unlabeled argument, and a times: parameter value of 1 will be supplied for you:

let d = Dog()
d.say("woof") // same as saying d.say("woof", times:1)

If you want repetition, call say(_:times:):

let d = Dog()
d.say("woof", times:3)

A parameter can be variadic. This means that the caller can supply as many values of this parameter’s type as desired, separated by comma; the function body will receive these values as an array.

To indicate in a function declaration that a parameter is variadic, follow it by three dots, like this:

func sayStrings(_ arrayOfStrings:String ...) {
    for s in arrayOfStrings { print(s) }
}

And here’s how to call it:

sayStrings("hey", "ho", "nonny nonny no")

The global print function takes a variadic first parameter, so you can output multiple values with a single command:

print("Manny", 3, true) // Manny 3 true

The print function’s default parameters dictate further details of the output. The default separator: (for when you provide multiple values) is a space, and the default terminator: is a newline; you can change either or both:

print("Manny", "Moe", separator:", ", terminator:", ")
print("Jack")
// output is "Manny, Moe, Jack" on one line

A function can declare a maximum of one variadic parameter (because otherwise it might be impossible to determine where the list of values ends).

A parameter whose local name is an underscore is ignored. The caller must supply an argument, but it has no name within the function body and cannot be referred to there. For example:

func say(_ s:String, times:Int, loudly _:Bool) {

No loudly parameter makes its way into the function body, but the caller must still provide the third parameter:

say("hi", times:3, loudly:true)

The declaration needn’t have an externalized name for the ignored parameter:

func say(_ s:String, times:Int, _:Bool) {

But the caller must still supply it:

say("hi", times:3, true)

What’s the purpose of this feature? It isn’t to satisfy the compiler, because the compiler doesn’t complain if a parameter is never referred to in the function body. I use it primarily as a kind of note to myself, a way of saying, “Yes, I know there is a parameter here, and I am deliberately not using it for anything.”

In the body of a function, a parameter is essentially a local variable. By default, it’s a variable implicitly declared with let. You can’t assign to it:

func say(_ s:String, times:Int, loudly:Bool) {
    loudly = true // compile error
}

If your code needs to assign to a parameter name within the body of a function, declare a var local variable inside the function body and assign the parameter value to it; your local variable can even have the same name as the parameter:

func say(_ s:String, times:Int, loudly:Bool) {
    var loudly = loudly
    loudly = true // no problem
}

In that code, loudly is a local variable; assigning to it doesn’t change the value of any variable outside the function body. However, it is also possible to configure a parameter in such a way that assigning to it does modify the value of a variable outside the function body! One typical use case is that you want your function to return more than one result. For example, here I’ll write a rather advanced function that removes all occurrences of a given character from a given string and returns the number of occurrences that were removed:

func removeCharacter(_ c:Character, from s:String) -> Int {
    var s = s
    var howMany = 0
    while let ix = s.characters.index(of:c) {
        s.remove(at:ix)
        howMany += 1
    }
    return howMany
}

And you call it like this:

let s = "hello"
let result = removeCharacter("l", from:s) // 2

That’s nice, but we forgot one little thing: the original string, s, is still "hello"! In the function body, we removed all occurrences of the character from the local copy of the String parameter, but this change didn’t affect the original string.

If we want our function to alter the original value of an argument passed to it, we must do the following:

Our removeCharacter(_:from:) now looks like this:

func removeCharacter(_ c:Character, from s: inout String) -> Int {
    var howMany = 0
    while let ix = s.characters.index(of:c) {
        s.remove(at:ix)
        howMany += 1
    }
    return howMany
}

And our call to removeCharacter(_:from:) now looks like this:

var s = "hello"
let result = removeCharacter("l", from:&s)

After the call, result is 2 and s is "heo". Notice the ampersand before name of s as the first argument in our function call! I like this requirement, because it forces us to acknowledge explicitly to the compiler, and to ourselves, that we’re about to do something potentially dangerous: we’re letting this function, as a side effect, modify a value outside of itself.

You may encounter variations on this pattern when you’re using Cocoa. The Cocoa APIs are written in C and Objective-C, so you probably won’t see the Swift term inout. You’ll probably see some mysterious type such as UnsafeMutablePointer. From your point of view as the caller, however, it’s the same thing. You’ll prepare a var variable and pass its address.

For instance, consider the problem of learning a UIColor’s RGBA components. There are four such components: the color’s red, green, blue, and alpha values. A function that, given a UIColor, returned the components of that color, would need to return four values at once — and that is something that Objective-C cannot do. So a different strategy is used. The UIColor method getRed(_:green:blue:alpha:) returns only a Bool reporting whether the component extraction succeeded. Instead of returning the actual components, it says: “You hand me four CGFloats as arguments, and I will modify them for you so that they are the results of this operation.” Here’s how the declaration for getRed(_:green:blue:alpha:) appears in Swift:

func getRed(_ red: UnsafeMutablePointer<CGFloat>,
    green: UnsafeMutablePointer<CGFloat>,
    blue: UnsafeMutablePointer<CGFloat>,
    alpha: UnsafeMutablePointer<CGFloat>) -> Bool

How would you call this function? The parameters are each an UnsafeMutablePointer to a CGFloat. You’ll create four var CGFloat variables beforehand, giving them each some value even though that value will be replaced when you call getRed(_:green:blue:alpha:). You’ll pass the addresses of those variables as arguments. Those variables are where the component values will be after the call; and you’ll probably be so sure that the component extraction will succeed, that you won’t even bother to capture the call’s actual result! So, for example:

let c = UIColor.purple
var r : CGFloat = 0
var g : CGFloat = 0
var b : CGFloat = 0
var a : CGFloat = 0
c.getRed(&r, green: &g, blue: &b, alpha: &a)
// now r, g, b, a are 0.5, 0.0, 0.5, 1.0

Sometimes, Cocoa will call your function with an UnsafeMutablePointer parameter, and you will want to change its value. To do this, you cannot assign directly to it, as we did with the inout variable s in our implementation of remove(from:character:). You’re talking to Objective-C, not to Swift, and this is an UnsafeMutablePointer, not an inout parameter. The technique here is to assign to the UnsafeMutablePointer’s pointee property. Here (without further explanation) is an example from my own code:

func popoverPresentationController(
    _ popoverPresentationController: UIPopoverPresentationController,
    willRepositionPopoverTo rect: UnsafeMutablePointer<CGRect>,
    in view: AutoreleasingUnsafeMutablePointer<UIView>) {
        view.pointee = self.button2
        rect.pointee = self.button2.bounds
}

There is one very common situation where your function can modify a parameter without declaring it as inout — namely, when the parameter is an instance of a class. This is a special feature of classes, as opposed to the other two object type flavors, enum and struct. String isn’t a class; it’s a struct. That’s why we had to use inout in order to modify a String parameter. So I’ll illustrate by declaring a Dog class with a name property:

class Dog {
    var name = ""
}

Here’s a function that takes a Dog instance parameter and a String, and sets that Dog instance’s name to that String. Notice that no inout is involved:

func changeName(of d:Dog, to newName:String) {
    d.name = newName
}

Here’s how to call it. There’s no inout, so we pass a Dog instance directly:

let d = Dog()
d.name = "Fido"
print(d.name) // "Fido"
changeName(of:d, to:"Rover")
print(d.name) // "Rover"

Observe that we were able to change a property of our Dog instance d, even though it wasn’t passed as an inout parameter, and even though it was declared originally with let, not var. This appears to be an exception to the rules about modifying parameters — but it isn’t. It’s a feature of class instances, namely that they are themselves mutable. In changeName(of:to:), we didn’t actually attempt to modify the parameter itself. To do that, we would have had to substitute a different Dog instance. That is not what we tried to do, and if we did want to do it, the Dog parameter would need to be declared inout (and d would have to be declared with var and we would have to pass its address as argument).

A function can be declared anywhere, including inside the body of a function. A function declared in the body of a function (also called a local function) is available to be called by later code within the same scope, but is completely invisible elsewhere.

This feature is an elegant architecture for functions whose sole purpose is to assist another function. If only function A ever needs to call function B, function B might as well be packaged inside function A.

Here’s a typical example from one of my apps (I’ve omitted everything except the structure):

func checkPair(_ p1:Piece, and p2:Piece) -> Path? {
    // ...
    func addPathIfValid(_ midpt1:Point, _ midpt2:Point) {
        // ...
    }
    for y in -1..._yct {
        addPathIfValid((pt1.x,y),(pt2.x,y))
    }
    for x in -1..._xct {
        addPathIfValid((x,pt1.y),(x,pt2.y))
    }
    // ...
}

What I’m doing in the first for loop (for y) and what I’m doing in the second for loop (for x) are the same — but with a different set of starting values. We could write out the functionality in full inside each for loop, but that would be an unnecessary and confusing repetition. (Such a repetition would violate the principle often referred to as DRY, for “Don’t Repeat Yourself.”) To prevent that repetition, we could refactor the repeated code into an instance method to be called by both for loops, but that exposes this functionality more broadly than we need, as it is called only by these two for loops inside checkPair. A local function is the perfect compromise.

Sometimes, it’s worth using a local function even when that function will be called in only one place. Here’s another example from my code (it’s actually another part of the same function):

func checkPair(_ p1:Piece, and p2:Piece) -> Path? {
    // ...
    if arr.count > 0 {
        func distance(_ pt1:Point, _ pt2:Point) -> Double { ❶
            // utility to learn physical distance between two points
            let deltax = pt1.0 - pt2.0
            let deltay = pt1.1 - pt2.1
            return sqrt(Double(deltax * deltax + deltay * deltay))
        }
        for thisPath in arr {
            var thisLength = 0.0
            for ix in thisPath.indices.dropLast() {
                thisLength += distance(thisPath[ix],thisPath[ix+1]) ❷
            }
            // ...
        }
    }
    // ...
}

Again, the structure is clear (even though the code uses some Swift features I haven’t discussed yet). Deep inside the function checkPair, a moment comes when I have an array (arr) of paths, and I need to know the length of every path. Each path is itself an array of points, so to learn its length, I need to sum the distances between each pair of points. To get the distance between a pair of points, I use the Pythagorean theorem. I could apply the Pythagorean theorem and express the calculation right there inside the for loop (for ix). Instead:

There is no savings whatever in the number of lines of code; in fact, declaring distance makes my code longer! Nor, strictly speaking, am I in danger of repeating myself; the application of the Pythagorean theorem is repeated many times, but it occurs at only one spot in my code, namely inside this one for loop. Nevertheless, abstracting the code into a more general distance-calculation utility makes my code much clearer: in effect, I announce in general form what I’m about to do (“Look! I’m going to calculate distances between points now!”), and then I do it. The function name, distance, gives my code meaning; it is more understandable and maintainable than if I had directly written out the steps of the distance calculation inline.

A function can call itself. This is called recursion. Recursion seems a little scary, rather like jumping off a cliff, because of the danger of creating an infinite loop; but if you write the function correctly, you will always have a “stopper” condition that handles the degenerate case and prevents the loop from being infinite:

func countDownFrom(_ ix:Int) {
    print(ix)
    if ix > 0 { // stopper
        countDownFrom(ix-1) // recurse!
    }
}

If you’ve never used a programming language where functions are first-class citizens, perhaps you’d better sit down now, because what I’m about to tell you might make you feel a little faint: In Swift, a function is a first-class citizen. This means that a function can be used wherever a value can be used. For example, a function can be assigned to a variable; a function can be passed as an argument in a function call; a function can be returned as the result of a function.

Swift has strict typing. You can only assign a value to a variable or pass a value into or out of a function if it is the right type of value. In order for a function to be used as a value, it needs to have a type. And indeed it does! Have you guessed what it is? A function’s signature is its type.

The chief purpose of using a function as a value is so that this function can later be called without a definite knowledge of what function it is. Here’s the world’s simplest (and silliest) example, just to show the syntax and structure:

func doThis(_ f:()->()) {
    f()
}

That is a function doThis that takes one parameter (and returns no value). The parameter, f, is itself a function; we know this because the type of the parameter is given as a function signature, ()->(), meaning (as you know) a function that takes no parameters and returns no value. The function doThis then calls the function f that it received as its parameter, by saying f().

Having declared the function doThis, how would you call it? To do so, you’d need to pass it a function as argument. Here’s one way to do that:

func doThis(_ f:()->()) {
    f()
}
func whatToDo() {
    print("I did it")
}
doThis(whatToDo)

First, we declare a function (whatToDo) of the proper type — a function that takes no parameters and returns no value. Then, we call doThis, passing as argument a function reference — in effect, the bare name of the function. Notice that we are not calling whatToDo here; we are passing it. Sure enough, this works: we pass whatToDo as argument to doThis; doThis calls the function that it receives as its parameter; and the string "I did it" appears in the console.

But what’s the point of being able to do that? If our goal is to call whatToDo, why don’t we just call it? What’s useful about being able to tell some other function to call it? In the example I just gave, there is nothing useful about it; I was just showing you the syntax and structure. But in real life, this is a very valuable thing to do. Encapsulating function-calling in a function can reduce repetition and opportunity for error. Moreover, the other function may call the parameter function in some special way; for example, it might call it after doing other things, or at some later time.

Here’s a case from my own code. A common thing to do in Cocoa is to draw an image, directly, in code. This involves four steps:

let size = CGSize(width:45, height:20)
UIGraphicsBeginImageContextWithOptions(size, false, 0) ❶
let p = UIBezierPath(
    roundedRect: CGRect(x:0, y:0, width:45, height:20), cornerRadius: 8)
p.stroke() ❷
let result = UIGraphicsGetImageFromCurrentImageContext()! ❸
UIGraphicsEndImageContext() ❹

That’s terribly ugly. The sole purpose of all that code is to obtain result, the image; but that purpose is buried in all the other code. At the same time, the entire structure is boilerplate; every time I do this in any app, step 1, step 3, and step 4 are exactly the same. Moreover, I live in mortal fear of forgetting a step; for example, if I were to omit step 4 by mistake, the universe would explode.

The only thing that’s different every time I draw is step 2. Thus, step 2 is the only part I should have to write out! The entire problem is solved by writing a utility function expressing the boilerplate:

func imageOfSize(_ size:CGSize, _ whatToDraw:() -> ()) -> UIImage {
    UIGraphicsBeginImageContextWithOptions(size, false, 0)
    whatToDraw()
    let result = UIGraphicsGetImageFromCurrentImageContext()!
    UIGraphicsEndImageContext()
    return result
}

My imageOfSize utility is so useful that I declare it at the top level of a file, where all my files can see it. To make an image, I perform step 2 (the actual drawing) in a function and pass that function as argument to the imageOfSize utility:

func drawing() {
    let p = UIBezierPath(
        roundedRect: CGRect(x:0, y:0, width:45, height:20),
        cornerRadius: 8)
    p.stroke()
}
let image = imageOfSize(CGSize(width:45, height:20), drawing)

Now that is a beautifully expressive and clear way to turn drawing instructions into an image.

The Cocoa API is full of situations where you’ll pass a function to be called by the runtime in some special way or at some later time. Some common Cocoa situations even involve passing two functions. For instance, when you perform view animation, you’ll often pass one function prescribing the action to be animated and another function saying what to do afterward:

func whatToAnimate() { // self.myButton is a button in the interface
    self.myButton.frame.origin.y += 20
}
func whatToDoLater(finished:Bool) {
    print("finished: \(finished)")
}
UIView.animate(withDuration:
    0.4, animations: whatToAnimate, completion: whatToDoLater)

That means: Change the frame origin (that is, the position) of this button in the interface, but do it over time (four-tenths of a second); and then, when that’s finished, print a log message in the console saying whether the animation was performed or not.

The Cocoa documentation will often describe a function to be passed in this way as a handler, and will refer it as a block, because that’s the Objective-C syntactic construct needed here; in Swift, it’s a function, so just think of it as a function and pass a function.

func doThis(_ f:()->()) {
    f()
}

typealias VoidVoidFunction = () -> ()
func dothis(_ f:VoidVoidFunction) {
    f()
}

Consider once again this earlier example:

func whatToAnimate() { // self.myButton is a button in the interface
    self.myButton.frame.origin.y += 20
}
func whatToDoLater(finished:Bool) {
    print("finished: \(finished)")
}
UIView.animate(withDuration:
    0.4, animations: whatToAnimate, completion: whatToDoLater)

There’s a slight bit of ugliness in that code. I’m declaring functions whatToAnimate and whatToDoLater, just because I want to pass those functions in the last line. I don’t really need the names whatToAnimate and whatToDoLater for anything, except to refer to them in the last line; neither the names nor the functions will ever be used again. Therefore, it would be nice to be able to pass just the body of those functions without a declared name.

That’s called an anonymous function, and it’s legal and common in Swift. To form an anonymous function, you do two things:

Let’s practice by transforming our named function declarations into anonymous functions. Here’s the named function declaration for whatToAnimate:

func whatToAnimate() {
    self.myButton.frame.origin.y += 20
}

Here’s an anonymous function that does the same thing. Notice how I’ve moved the parameter list and return type inside the curly braces:

{
    () -> () in
    self.myButton.frame.origin.y += 20
}

Here’s the named function declaration for whatToDoLater:

func whatToDoLater(finished:Bool) {
    print("finished: \(finished)")
}

Here’s an anonymous function that does the same thing:

{
    (finished:Bool) -> () in
    print("finished: \(finished)")
}

Now that we know how to make anonymous functions, let’s use them. The point where we need the functions is the point where we’re passing arguments to animate(withDuration:animations:completion:). We can create and pass anonymous functions right at that point, like this:

UIView.animate(withDuration:0.4,
    animations: {
        () -> () in
        self.myButton.frame.origin.y += 20
    },
    completion: {
        (finished:Bool) -> () in
        print("finished: \(finished)")
    }
)

We can make the same improvement in the way we call the imageOfSize function from the preceding section. Earlier, we called that function like this:

func drawing() {
    let p = UIBezierPath(
        roundedRect: CGRect(x:0, y:0, width:45, height:20),
        cornerRadius: 8)
    p.stroke()
}
let image = imageOfSize(CGSize(width:45, height:20), drawing)

We now know, however, that we don’t need to declare the drawing function separately. We can call imageOfSize with an anonymous function:

let image = imageOfSize(CGSize(width:45, height:20), {
    () -> () in
    let p = UIBezierPath(
        roundedRect: CGRect(x:0, y:0, width:45, height:20),
        cornerRadius: 8)
    p.stroke()
})

Anonymous functions are very commonly used in Swift, so make sure you can read and write that code! Anonymous functions, in fact, are so common and so important, that some shortcuts for writing them are provided:

When writing anonymous functions, you will frequently find yourself taking advantage of all the omissions you are permitted. In addition, you’ll often shorten the layout of the code (though not the code itself) by putting the whole anonymous function together with the function call on one line. Thus, Swift code involving anonymous functions can be extremely compact.

Here’s a typical example. We start with an array of Int values and generate a new array consisting of all those values multiplied by 2, by calling the map(_:) instance method. The map(_:) method of an array takes a function that takes one parameter of the same type as the array’s elements, and returns a new value; here, our array is made of Int values, and we are passing to the map(_:) method a function that takes one Int parameter and returns an Int. We could write out the whole function, like this:

let arr = [2, 4, 6, 8]
func doubleMe(i:Int) -> Int {
    return i*2
}
let arr2 = arr.map(doubleMe) // [4, 8, 12, 16]

That, however, is not very Swifty. We don’t need the name doubleMe for anything else, so this may as well be an anonymous function:

let arr = [2, 4, 6, 8]
let arr2 = arr.map ({
    (i:Int) -> Int in
    return i*2
})

Fine, but now let’s start shortening our anonymous function. Its parameter type is known in advance, so we don’t need to specify that. Its return type is known by inspection of the function body, so we don’t need to specify that. There’s just one parameter and we are going to use it, so we don’t need the in line as long we refer to the parameter as $0. Our function body consists of just one statement, and it is a return statement, so we can omit return. And map(_:) doesn’t take any other parameters, so we can omit the parentheses and follow the name directly with a trailing function:

let arr = [2, 4, 6, 8]
let arr2 = arr.map {$0*2}

It doesn’t get any Swiftier than that!

A pattern that’s surprisingly common in Swift is to define an anonymous function and call it, all in one move:

{
    // ... code goes here
}()

Notice the parentheses after the curly braces. The curly braces define an anonymous function body; the parentheses call that anonymous function.

Why would anyone do such a thing? If you want to run some code, you can just run it; why would you embed it in a deeper level as a function body, only to turn around and run that function body immediately?

For one thing, an anonymous function can be a good way to make your code less imperative and more, well, functional: an action can be taken at the point where it is needed, rather than in a series of preparatory steps. Here’s a common Cocoa example: we create and configure an NSMutableParagraphStyle and then use it as an argument in a call to the NSMutableAttributedString method addAttribute(_:value:range:), like this:

let para = NSMutableParagraphStyle()
para.headIndent = 10
para.firstLineHeadIndent = 10
// ... more configuration of para ...
content.addAttribute( // content is an NSMutableAttributedString
    NSParagraphStyleAttributeName,
    value:para,
    range:NSRange(location:0, length:1))

I find that code ugly. We don’t need para except to pass it as the value: argument within the call to addAttribute(_:value:range:), so it would be much nicer to create and configure it right there within the call, as the value: argument. That sounds like an anonymous function — except that the value: parameter is not a function, but an NSMutableParagraphStyle object. We can solve the problem by providing, as the value: argument, an anonymous function that produces an NSMutableParagraphStyle object and calling it so that it does produce an NSMutableParagraphStyle object:

content.addAttribute(
    NSParagraphStyleAttributeName,
    value: {
        let para = NSMutableParagraphStyle()
        para.headIndent = 10
        para.firstLineHeadIndent = 10
        // ... more configuration of para ...
        return para
    }(),
    range:NSRange(location:0, length:1))

I’ll demonstrate some further uses of define-and-call in Chapter 3.

Swift functions are closures. This means they can capture references to external variables in scope within the body of the function. What do I mean by that? Well, recall from Chapter 1 that code in curly braces constitutes a scope, and this code can “see” variables and functions declared in a surrounding scope:

class Dog {
    var whatThisDogSays = "woof"
    func bark() {
        print(self.whatThisDogSays)
    }
}

In that code, the body of the function bark refers to a variable whatThisDogSays. That variable is external to the body of the function, because it is declared outside the body of the function. It is in scope for the body of the function, because the code inside the body of the function can see it. And the code inside the body of the function refers to it — it says, explicitly, whatThisDogSays.

So far, so good; but we now know that the function bark can be passed as a value. In effect, it can travel from one environment to another! When it does, what happens to that reference to whatThisDogSays? Let’s find out:

func doThis(_ f : (Void) -> Void) {
    f()
}
let d = Dog()
d.whatThisDogSays = "arf"
let barkFunction = d.bark
doThis(barkFunction) // arf

We run that code, and "arf" appears in the console.

Perhaps that result doesn’t seem very surprising to you. But think about it. We do not directly call d.bark(). We make a Dog instance and pass its bark function as a value into the function doThis. There, it is called. Now, whatThisDogSays is an instance property of a particular Dog. Inside the function doThis there is no whatThisDogSays. Indeed, inside the function doThis there is no Dog instance! Nevertheless the call f() still works. The function d.bark, as it is passed around, can still see that variable whatThisDogSays, declared outside itself, even though it is called in an environment where there is no longer any Dog instance and no longer any instance property whatThisDogSays.

But there’s more. I’ll move the line where we set d.whatThisDogSays to after we assign d.bark into our variable barkFunction:

func doThis(_ f : (Void) -> Void) {
    f()
}
let d = Dog()
let barkFunction = d.bark
d.whatThisDogSays = "arf" // *
doThis(barkFunction) // arf

Do you see what this proves? At the time we assigned d.bark to barkFunction, d.whatThisDogSays was "woof". We then changed d.whatThisDogSays to "arf", and passed barkFunction into doThis, where it was called — and we got "arf". This proves that barkFunction is maintaining its reference to this actual Dog, the one that we call d. The bark function, as it is passed around, is carrying its environment with it — including the instance of which it is an instance method (because it refers, in its body, to self). That environment is still there later when the bark function is called in some other environment. So, by “capture” I mean that when a function is passed around as a value, it carries along its internal references to external variables. That is what makes a function a closure.

func imageOfSize(_ size:CGSize, _ whatToDraw:() -> ()) -> UIImage {
    UIGraphicsBeginImageContextWithOptions(size, false, 0)
    whatToDraw()
    let result = UIGraphicsGetImageFromCurrentImageContext()!
    UIGraphicsEndImageContext()
    return result
}

let image = imageOfSize(CGSize(width:45, height:20)) {
    let p = UIBezierPath(
        roundedRect: CGRect(x:0, y:0, width:45, height:20),
        cornerRadius: 8)
    p.stroke()
}

let sz = CGSize(width:45, height:20)
let image = imageOfSize(sz) {
    let p = UIBezierPath(
        roundedRect: CGRect(origin:CGPoint.zero, size:sz),
        cornerRadius: 8)
    p.stroke()
}

func makeRoundedRectangle(_ sz:CGSize) -> UIImage {
    let image = imageOfSize(sz) {
        let p = UIBezierPath(
            roundedRect: CGRect(origin:CGPoint.zero, size:sz),
            cornerRadius: 8)
        p.stroke()
    }
    return image
}

self.myImageView.image = makeRoundedRectangle(CGSize(width:45, height:20))

func makeRoundedRectangleMaker(_ sz:CGSize) -> () -> UIImage { ❶
    func f () -> UIImage { ❷
        let im = imageOfSize(sz) {
            let p = UIBezierPath(
                roundedRect: CGRect(origin:CGPoint.zero, size:sz),
                cornerRadius: 8)
            p.stroke()
        }
        return im
    }
    return f ❸
}

let maker = makeRoundedRectangleMaker(CGSize(width:45, height:20))

let maker = makeRoundedRectangleMaker(CGSize(width:45, height:20))
self.myImageView.image = maker()

func makeRoundedRectangleMaker(_ sz:CGSize) -> () -> UIImage {
    func f () -> UIImage {
        let im = imageOfSize(sz) { // *
            let p = UIBezierPath(
                roundedRect: CGRect(origin:CGPoint.zero, size:sz), // *
                cornerRadius: 8)
            p.stroke()
        }
        return im
    }
    return f
}

let maker = makeRoundedRectangleMaker(CGSize(width:45, height:20))

func makeRoundedRectangleMaker(_ sz:CGSize) -> () -> UIImage {
    func f () -> UIImage {
        return imageOfSize(sz) {
            let p = UIBezierPath(
                roundedRect: CGRect(origin:CGPoint.zero, size:sz),
                cornerRadius: 8)
            p.stroke()
        }
    }
    return f
}

func makeRoundedRectangleMaker(_ sz:CGSize) -> () -> UIImage {
    return {
        return imageOfSize(sz) {
            let p = UIBezierPath(
                roundedRect: CGRect(origin:CGPoint.zero, size:sz),
                cornerRadius: 8)
            p.stroke()
        }
    }
}

func makeRoundedRectangleMaker(_ sz:CGSize) -> () -> UIImage {
    return {
        imageOfSize(sz) {
            let p = UIBezierPath(
                roundedRect: CGRect(origin:CGPoint.zero, size:sz),
                cornerRadius: 8)
            p.stroke()
        }
    }
}

func pass100 (_ f:(Int)->()) {
    f(100)
}

var x = 0
print(x)
func setX(newX:Int) {
    x = newX
}
pass100(setX)
print(x)

func countAdder(_ f: @escaping ()->()) -> () -> () {
    var ct = 0
    return {
        ct = ct + 1
        print("count is \(ct)")
        f()
    }
}

func greet () {
    print("howdy")
}
let countedGreet = countAdder(greet)
countedGreet()
countedGreet()
countedGreet()

count is 1
howdy
count is 2
howdy
count is 3
howdy

func funcCaller(f:()->()) {
    f()
}

func funcMaker() -> () -> () {
    return { print("hello world") }
}

func funcPasser(f:()->()) -> () -> () { // compile error
    return f
}

func funcPasser(f:@escaping ()->()) -> () -> () {
    return f
}

Return once more to makeRoundedRectangleMaker:

func makeRoundedRectangleMaker(_ sz:CGSize) -> () -> UIImage {
    return {
        imageOfSize(sz) {
            let p = UIBezierPath(
                roundedRect: CGRect(origin:CGPoint.zero, size:sz),
                cornerRadius: 8)
            p.stroke()
        }
    }
}

There’s something I don’t like about this method: the size of the rounded rectangle that it creates is a parameter (sz), but the cornerRadius of the rounded rectangle is hard-coded as 8. I’d like the ability to specify a value for the corner radius as well. I can think of two ways to do it. One is to give makeRoundedRectangleMaker itself another parameter:

func makeRoundedRectangleMaker(_ sz:CGSize, _ r:CGFloat) -> () -> UIImage {
    return {
        imageOfSize(sz) {
            let p = UIBezierPath(
                roundedRect: CGRect(origin:CGPoint.zero, size:sz),
                cornerRadius: r)
            p.stroke()
        }
    }
}

And we would then call it like this:

let maker = makeRoundedRectangleMaker(CGSize(width:45, height:20), 8)

But there’s another way. The function that we are returning from makeRoundedRectangleMaker takes no parameters. Instead, it could take the extra parameter:

func makeRoundedRectangleMaker(_ sz:CGSize) -> (CGFloat) -> UIImage {
    return {
        r in
        imageOfSize(sz) {
            let p = UIBezierPath(
                roundedRect: CGRect(origin:CGPoint.zero, size:sz),
                cornerRadius: r)
            p.stroke()
        }
    }
}

Now makeRoundedRectangleMaker returns a function that, itself, takes one parameter, so we must remember to supply that when we call it:

let maker = makeRoundedRectangleMaker(CGSize(width:45, height:20))
self.myImageView.image = maker(8)

If we don’t need to conserve maker for anything, we can of course do all that in one line — a function call that yields a function which we immediately call to obtain our image:

self.myImageView.image = makeRoundedRectangleMaker(CGSize(width:45, height:20))(8)

Throughout this chapter, wherever I wanted to refer to a function by name — for example, in order to pass it as argument to another function — I’ve been using its bare name, like this:

func whatToAnimate() { // self.myButton is a button in the interface
    self.myButton.frame.origin.y += 20
}
func whatToDoLater(finished:Bool) {
    print("finished: \(finished)")
}
UIView.animate(withDuration:
    0.4, animations: whatToAnimate, completion: whatToDoLater) // *

A bare name like whatToAnimate or whatToDoLater is a function reference. Use of the bare name as a function reference is legal because it’s unambiguous in this particular context: thus, there’s only one function called whatToDoLater in scope, and I’m using its name as argument in a function call where the parameter type is known (namely, (Bool) -> Void).

But now consider the following situation. Just as I can pass a function as an argument, I can assign a function as a value to a variable. And suppose I have two functions with the same name, one that takes a parameter, and one that doesn’t:

class Dog {
    func bark() {
        print("woof")
    }
    func bark(_ loudly:Bool) {
        if loudly {
            print("WOOF")
        } else {
            self.bark()
        }
    }
    func test() {
        let barkFunction = bark // compile error
        // ...
    }
}

That code won’t compile, because the bare name bark is ambiguous in this context: which bark method does it refer to? To solve this problem, Swift 2.2 introduced a more elaborate notation allowing you to refer to a function more precisely. This notation has two parts:

In our bark example, use of the full name solves the problem if the function to which we want a reference is the one that takes a parameter:

class Dog {
    func bark() {
        // ... as before ...
    }
    func bark(loudly:Bool) {
        // ... as before ...
    }
    func test() {
        let barkFunction = bark(_:) // fine
    }
}

But use of the full name doesn’t solve the problem if the function to which we want a reference is the one that takes no parameters, because in that case the full name is the bare name, which is exactly what’s ambiguous in this context. Use of the signature solves the problem:

class Dog {
    func bark() {
        // ... as before ...
    }
    func bark(loudly:Bool) {
        // ... as before ...
    }
    func test() {
        let barkFunction = bark as (Void) -> Void // fine
    }
}

Obviously, an explicit signature is needed also when a function is overloaded. For example:

class Dog{
    func bark() {
    }
    func bark(_ loudly:Bool) {
    }
    func bark(_ times:Int) {
    }
    func test() {
        let barkFunction = bark(_:) // compile error
    }
}

Here, we have said that we want the bark that takes one parameter, but there are two such bark functions, one whose parameter is a Bool, the other whose parameter is an Int. The signature disambiguates (and we can use the bare name):

let barkFunction = bark as (Int) -> Void // "times", not "loudly"

class Dog {
    func bark() {
    }
    func bark(_ loudly:Bool) {
    }
    func test() {
        let f = {
            return self.bark(_:) // self required here
        }
    }
}

class Cat {
    func purr() {
    }
}
class Dog {
    let cat = Cat()
    func test() {
        let purrFunction = cat.purr
    }
}

class Cat {
    func purr() {
    }
}
class Dog {
    func bark() {
    }
    func test() {
        let barkFunction = Dog.bark // legal but not necessary
        let purrFunction = Cat.purr
    }
}

class ViewController : UIViewController {
    @IBOutlet var b : UIButton!
    func viewDidLoad() {
        super.viewDidLoad()
        self.b.addTarget( // prepare to crash!
            self, action: "buttonPressed", for: .touchUpInside)
    }
    func buttonPressed(_ sender: Any) {
        // ...
    }
}

class ViewController : UIViewController {
    @IBOutlet var button : UIButton!
    func viewDidLoad() {
        super.viewDidLoad()
        self.b.addTarget(
            self, action: #selector(buttonPressed), for: .touchUpInside)
    }
    func buttonPressed(_ sender: Any) {
        // ...
    }
}