# Writing Algorithms on Collections in Swift

edit: this post has been updated to Swift as of Xcode 6.1 (Swift 1.1).

Suppose you want a new algorithm that checks if every member of an array fulfills a given criteria.

Your first thought might be to add it as an extension of Array:1

```extension Array {
func all_of<B: BooleanType>
(predicate: (Element) -> B) -> Bool {
for e in self {
if !predicate(e) {
return false
}
}
return true
}
}
```

This function takes a predicate (a function that takes an element and returns true or false), and applies it to every member of the array, only returning true if it was true for every member.

Note we specify a template argument, `B: BooleanType`, that allows the predicate to return not just a Bool but any type that can behave like a Bool (such as `ObjCBool`)2.

We can test it works easily:

```let isEven = { (\$0 % 2) == 0 }
let mixed = Array(1...4)     // [1, 2, 3, 4]
let doubled = map(1...4) { \$0 * 2 }
let evens = Array(doubled)   // [2, 4, 6, 8]

mixed.all_of(isEven)  // false
evens.all_of(isEven)  // true
```

Incidentally, the above shows a nice trick that’s useful for testing collection algorithms, which is that arrays can be initialized with sequences, such as ranges. So if you quickly want an array of increasing numbers, you can write `Array(begin...end)`. If you want something more complicated, you can pass a range to `map` or `filter` to alter the range first.

This implementation is nice because it’s now built into `Array`, but there are a few downsides.

Firstly, what if you wanted a slightly different version `all_of_equal`, that just took a value and confirmed if every entry was equal to that value? You’ll need to test for equality, so Element will need to be Equatable. You might think you’d specify a function that goes like this:

```extension Array {
func all_of_equal<Element: Equatable>
(value: Element) -> Bool {
return self.all_of { \$0 == value }
}
}
```

Nope, that won’t work. The problem is that you can’t further constrain `Element` within `Array` to be `Equatable`. What if you created an array of something that didn’t conform to Equatable? Would this no longer be allowed now you’ve added this method? Or should this method not be callable? Neither of these are palatable so the language just won’t let you do it.

Instead, you need to define a non-member function that takes an Array and an Element. Then you can constrain that element as much as you like:

```func all_of<E, B: BooleanType>
(a: Array<E>, predicate: (E) -> B) -> Bool {
for e in a {
if !predicate(e) {
return false
}
}
return true
}

func all_of_equal<E: Equatable>
(a: Array<E>, rhs: E) -> Bool {
return all_of(a) { \$0 == rhs }
}
```

In fact, because of Swift’s operator overloading, you can even give it the same name:

```func all_of<E: Equatable>
(a: Array<E>, rhs: E) -> Bool {
return all_of(a) { \$0 == rhs }
}

// calls the version that takes an equatable value
all_of([1,1,1], 1)

// calls the version that takes a closure
all_of([1,1,1]) { \$0%2 == 1 }
```

The second benefit of defining this as a non-member function is you can generalize it to apply not just to arrays, but any kind of collection.3 To do this, you need to extend the generic parameter clause in a couple of ways:

```func all_of<E, C: CollectionType, L: BooleanType
where E == C.Generator.Element>
(c: C, predicate: (E) -> L) -> Bool {
for e in c {
if(!predicate(e)) {
return false
}
}
return true
}
```

First, we swap out `Array` for a type of `Collection`, by specifying a generic placeholder C that must be a collection. Then, we further constrain the collection to contain types `E`, which are the type of input our predicate will take.

Strictly speaking, we don’t need to include the placeholder `E`. You could replace it in the predicate definition with `C.Generator.Element`. But you might find it’s cleaner to create a placeholder for it, especially if you apply further constraints to `E`.

Now, we can use this function on not just arrays, but any type of collection, such as ranges directly:

```let isEven = { (\$0 % 2) == 0 }
all_of(1...4, isEven)  // returns false
```

or other types of collection:

```let doubled = map(1...4) { \$0 * 2 }
all_of(doubled, isEven)  // returns true
```

There’s one final improvement that could be made. Collections implement the Sequence protocol, which also gives us enough to iterate over the elements, checking the predicate. So we could rewrite all_of even more generally:

```func all_of<E, S: SequenceType, B: BooleanType
where E == S.Generator.Element>
(sequence: S, predicate: (E) -> B) -> Bool {
for e in sequence {
if(!predicate(e)) {
return false
}
}
return true
}
```

Because Sequences behave differently, we don’t need to mandate a `ForwardIndex` to make them work with the `for`.

There are some times you still want to use collections rather than sequences. If we were writing a different algorithm, say `find_first_of`, that we wanted to return an index into the collection of the first occurrence, we’d want to stick with an algorithm that works on collections. Also, collections imply deterministic results over multiple iterations, and consistent size, which some algorithms might rely on. But not in the case of `all_of`, so `SequenceType` is a better choice.

1. The most important question facing the Swift community today: how do you split long function footprints over multiple lines?
2. In fact, the Swift standard library docs explicitly state that `Bool` and `ObjCBool` should really only be the two types that ever implement `BooleanType`, so maybe you could say screw it and just make the predicate return a `Bool`. That’s what the predicates for std lib functions like `filter` do. But then, that wouldn’t make for quite so educational a blog post.
3. You might be thinking, I know, I’ll extend `CollectionType`! But `CollectionType` is a protocol, and you can’t extend protocols with implementations. What you want is something like traits or mixins. Swift doesn’t have those (yet, hopefully).

# Closures and Closure Expressions are two different things

Bit of quick monday morning pedantry. fuckingclosuresyntax.com, while fun and useful, is perpetuating a subtle conflation of two things, that most Swift programmers have silently adopted, that in turn is probably confusing a lot of beginners.

This function returns a closure:

```func return_a_closure() -> () -> (Int) {
acc = i
func the_closure() -> Int {
return ++acc
}
}
```

Even though `func` was used to define the closure, not `{ }`, it is still a closure, because it’s a function that captures an environment of variables (in this case `acc`).

The `{ }` syntax alternative to `func` is called a “closure expression” but it doesn’t make the function returned any more closurey than the example above.

If you already know the difference, it’s natural to drop the word “expression” and just call them closures, and this is what most people writing about Swift are doing. This was inevitable as soon as Apple decided to call them closure expressions, rather than blocks or lambdas or anonymous functions. But this conflation seems to be confusing a lot of people coming to Swift without a background in first-class function and closures. The opening of the closures chapter in the official Swift book makes the difference quite clear, but still the confusion remains.

The bright side is this might be forcing new developers to learn about closures, by throwing them in the terminology deep end. If Apple had stuck with Objective-C’s term, blocks, maybe fewer programmers would be learning about variable capture (plus, fuckingblocksyntax.com was already taken).

What would have been really cool? If Apple had done away with the `func` keyword altogether, leaving closure expressions assigned to variables as the only way to declare functions. But that would have pushed way too many people out of their comfort zone.

If all this is nonsense-speak to you, try reading this tutorial.

# Implementing some Ruby builtins in Swift

Type `1.` into `irb` and hit tab, and it’ll ask you if you want to see all 105 possibilities. Try it with `[ ]` and you’ll be offered 155. Ruby comes with a lot of built-in methods on its default types.

It’s debatable how useful all of these are. The idiom in Swift seems much more to be like in the C++ STL, where there are algorithms that operate on collections, rather than collections having methods that operate on themselves. To see more about this, read this article on writing algorithms against collections.

But for the sake of looking at a few Swift language features, let’s implement some of the Ruby popular ones. Maybe they’d be useful making a Ruby refugee feel at home.

First off, the Int loops. Lots of “hey look, ruby is cool” intros kick off with this one:

```10.times do |i|
"ruby is cool!"
end
```

This is pretty easy to add to the Swift Int using an extension:

```extension Int {
func times(f: () -> () ) {
for _ in 0..self {
f()
}
}
}

10.times { "swift is cool too!" }
```

Note the _ instead of a variable in the for, because the value isn’t actually needed.

Next, two `for` alternatives, `upto` and `downto`:

```1.upto(3) {|i| print "#{i}.. "} # prints 1.. 2.. 3..
3.downto(1) {|i| print "#{i}.. "} # prints 3.. 2.. 1..
```

in Swift would be:

```extension Int {
func upto(n: Int, f: (Int) -> () ) {
for i in self...n {
f(i)
}
}
func downto(n: Int, f: (Int) -> () ) {
for i in reverse(n...self) {
f(i)
}
}
}
```

Note the use of the inclusive `...` this time, unlike with `times` which used the convention of a zero base up to but not including `n` so needed non-inclusive `..`, because this time we want to start at `self` and count inclusively to `n`. Humorously, Ruby also has inclusive and exclusive ranges but `..` and `...` are the opposite way around.

For `downto`, the range is wrapped in a `reverse` in order to count backwards.

Next, some extensions to array, in a similar vein to `map` or `reduce`.

Ruby’s `each` is like `map`, but doesn’t generate any return value:

```extension Array {
func each(f: (Element) -> ()) {
for e in self {
f(e)
}
}
}
```

`Element` is a Type Property representing the type of value the Array contains, to this function works generically for type contained by array.

Ruby’s `reverse_each` does the same but in the opposite direction:

```extension Array {
func each(f: (Element) -> ()) {
for e in Swift.reverse(self) {
f(e)
}
}
}
```

Again, we use `reverse` to go backwards through the array. Wait, you might think, isn’t it inefficient to reverse the array just to iterate over it? But that’s not what `reverse` does – instead it generates a lazy collection that serves up the values in reverse order.

Note, we have to prefix it `Swift.reverse` to disambiguate it from the `Array` member function `reverse` – which would result in creating a whole new array in reversed order, if we used it.

Ruby’s `delete_if` is the opposite of Swift’s `filter` – it takes a discriminator function and returns any elements that don’t match. We could easily just implement it from scratch with a for loop, but instead let’s try and implement it by re-using `filter`.

One way to do this is to first create what’s called a “decorator”. Decorators are functions that take other functions, and return a new function that has changed the behaviour of the original function in some useful way.

What we want is a decorator that takes a function that returns a boolean, and then returns the opposite of that. Here it is:

```// function that takes a function, f, that takes an element
// and returns a bool, and returns a function that applies f
// then returns the opposite
func not_f<T>(f: (T)->Bool) -> (T)->Bool {
// this returns a closure that captures f
return { !f(\$0) }
}
```

If you’re a bit hazy on closures and variable capture, read this.

Armed with `not_f`, we can define `delete_if`:

```extension Array {
func delete_if(f: (Element) -> Bool) -> Element[] {
return self.filter(not_f(f))
}
}
```

Finally, Ruby’s equivalent of `filter` is called `select`. It’s identical, it’s just called by a different name. Is there some way we could alias `filter` if we wanted?

Yup, like this:

```extension Array {
var select: ((Element) -> Bool) -> Element[] {
return Array.filter(self)
}
}
```

You can now use `select` in exactly the same way you use `filter`. This is quite a silly thing to do, but it does demonstrate a couple of language features: read-only computed properties that return closures, and references to member functions.

Read-only computed properties are used like regular properties i.e. can be accessed using the dot syntax, but behave like functions that take no arguments and return a value. In this case we have defined a property select that returns a function when you call it. We’re just returning an existing member function (more on that next) but you could have more complex logic that created and returned different kinds of closures.

The reason it’s nice to implement these as computed properties is you don’t need to use a `()` after the property name. This means if you want to compute a function for someone to use, they can use it like this: `x.computedfun()`. If `computedfun` was itself a function, you’d have to write this: `x.computedfun()()`, which looks odd. Other than that, they behave just like functions that return functions.

So what is `select` actually returning? To understand that, you need need to realize you can reference a classes’ member functions. See the following code:

```class MyClass {
let n: Int

init(_ i: Int) { n = i }

func multiply(i: Int) {
println("n: \(n) * i: \(i) = \(n*i)")
}

println("n: \(n) + i: \(i) = \(n*i)")
}
}

let a = MyClass(2)
let b = MyClass(5)

// prints "n: 2 * i: 10 = 20"
a.multiply(10)

// prints "n: 5 + i: 10 = 50"

// this takes a reference to the member
// function multiply of MyClass
var memfunref = MyClass.multiply

// you can't use memfunref directly.
// you have to apply an instance of
// MyClass to it:
var instancefunref = memfunref(a)

// now you can call it, and it's
// like calling a.multiply, so
// this prints "n: 2 * i: 10 = 20"
instancefunref(10)

// MyClass.add has the same type as
// MyClass.multiply, they're both (Int)->(),
// so you can assign it to memfunref too:

// and apply a different instance of MyClass
instancefunref = memfunref(b)

// this prints "n: 5 + i: 10 = 50"
instancefunref(10)

// or you can skip the instancefunref step
// prints "n: 5 + i: 10 = 50" again
memfunref(b)(10)
```

Now we can see what that computed property is doing. It’s returning the member function `filter` of `Array`, then applying `self` to it, and returning that. The caller then can call the returned function `()` and it runs `filter` against the object they fetched it from. Like I said, bit silly, but it demonstrates a feature that could probably be put to better use in other cases.

If you liked this post, this one is also about implementing Ruby features in Swift, in this case implementing the `||=` operator using the `@auto_closure` Swift feature.

# Implementing Ruby’s ||= operator in Swift using @autoclosure

edit: this has been updated for Swift as of Xcode 6.1 (Swift 1.1)

A common idiom in Ruby is to assign a value to a variable only if that variable isn’t already set, using the `||=` operator:

```s ||= "default value"
```

Swift doesn’t provide such an operator out of the box, but using some of the features of the language, it’s possible to implement one.

### Simple first implementation

First let’s try implementing it just for string types. We need to define the operator itself first:

```infix operator ||= {
associativity right
precedence 90
assignment
}
```

And then implement it with a function:

```func ||=(inout lhs: String?, rhs: String) {
if(lhs == nil) {
lhs = rhs
}
}
```

Note the use of the `assignment` attribute on the operator definition, and the `inout` parameter on the left-hand side, which is the variable being assigned to.

This works. If you try the following

```var s: String?
s ||= "first assignment"
s ||= "second assignment"
```

the second assignment will have no effect on `s` – it will keep the value “first assignment”.

### Using generics to apply to any type

What about implementing this with generics, so it will work not just for String but for any type? That’s pretty simple:

```func ||=<T>(inout lhs: T?, rhs: T) {
if(lhs == nil) {
lhs = rhs
}
}
```

Now you can use our `||=` on any type optional type – `String?`, `Int?`, or any user-defined class.

### Using autoclosure to avoid unncessary evaluation

Our `||=` still doesn’t quite match the Ruby version. If the value on the left-hand side is already set, the statement on the right-hand side is never executed. This is important if, for example, the right-hand side were a function with other side-effects, or an expensive computation.

But by default in Swift, any statement passed to a parameter is fully executed first. To replicate the Ruby functionality, we have to use an attribute in Swift called `autoclosure`. This is used like this:

```func ||=<T>(inout lhs: T?, rhs: @autoclosure () -> T) {
if(lhs == nil) {
lhs = rhs()
}
}
```

What `autoclosure` does is wrap the arguments suppled in a closure, for later execution. Then, if they aren’t needed, they are never executed. If they are needed (in this case, because `lhs` is `nil`), the closure can be called (note the new type for rhs, and the parenthesis after rhs, indicating it is now calling a function).

To check this works, try the following, which should only print “I’ve been run” once to the console:

```func printlnWhenRun() -> Int {
println("I've been run")
return 0
}
var i: Int?
i ||= printlnWhenRun()
i ||= printlnWhenRun()
```

### Implementing for Boolean values

This works great for optional types, but what about the more conventional behaviour, a compound logical-OR-and-assign operator for boolean values?

Despite listing it in the Expressions precedence section of the language reference, this doesn’t appear to be implemented in Swift natively.

edit: it’s now been removed from the precedence section. You can still declare it as below though.

No problem though, we can just implement it ourselves. Here it is:

```func ||=<T: BooleanType>(inout lhs: T, rhs: @autoclosure () -> T) {
if(!lhs) {
lhs = rhs()
}
}
```

Note the `BooleanType` type constraint after the type parameter. This is necessary because we need to guarantee that you can pass whatever type is used into the `if` statement. This wasn’t necessary with the other version because it was the optional qualifier supplying this ability.1

But doesn’t this clash with the other definition? Nope. A combination of the type constraint on the logical version, and the presence of the optional parameter on the optional-assignment version, means the possible uses of these two functions are entirely disjoint, and the Swift compiler will pick the right one for you. Even a `Bool?` type will go to the optional-assignment version.2

### Using lazy properties instead of `||=`

Having done all of this, you could argue `||=` isn’t all that useful in Swift because of different feature, lazy properties. These are properties of a class or struct that are only initialized for the first time when they are used – in much the same way as Ruby devs use `||=`. Below is some code showing this in action:

```class MyClass {
lazy var complexThing = CreateComplexThing()
}
var c = MyClass()
// ... maybe some time later
var thing = c.complexThing  // CreateComplexThing() runs now
```

Obviously this only applies when your property is part of a class, not when you’re declaring a variable in a function, so maybe there’s still a place for `||=`. But if not, at least we learned something implementing it.

1. And there’s no need to constrain to objects with the ability to assign to each other – they all have that ability. There’s no “Assignable” protocol. Be nice if there were – that would imply you could overload “=”. But this ain’t C++.
2. It is possible to write two generic functions that overlap in their inputs, in which case you will get an “use of unresolved identifier” error from the compiler when you call the function (note, not when you define the overlapping function, which is a break from other features of generics when you get a compiler error at the time of definition rather than use).

# Rundown of how each Effective C++ item relates to Swift

In this post we talked about how some of the items in Effective C++ might apply to Swift.

Many of the entries highlighted some limitations on the part of Swift, so some might think this post was a criticism of Swift.  Actually far from it – many of the items in Effective C++ are pointing out dangers of C++ where you can shoot yourself in the foot if you aren’t careful.  In most cases, when you look at the equivalent issue in Swift, it’s a non-issue.

For completeness, here is a rundown of every item, what kind of article it is, and how it applies to Swift:

# Mining “Effective C++” for ideas on Swift

Effective C++ by Scott Meyers is an amazingly good book. For me, it is to programming books like Watchmen is to comics – everything else I read, I feel disappointed that it isn’t as good. If you program C++ and you haven’t read it yet, get on it!

There are also several articles in the book that apply to any language – Item 28: Avoid returning “handles” to object internals, Item 32: Make sure public inheritance models “is-a.”, Item 53: Pay attention to compiler warnings. Even if you aren’t ever planning to write C++, maybe grab a friend’s copy and give it a skim.

There is a fair amount of material in there that is also applicable to Swift. Many features of modern C++ programming have fed into Swift – which isn’t surprising given Swift was born out of the LLVM team, and LLVM is written in C++. Here are a few items from the book, and how they might also apply to Swift.

edit: for the completists amongst you, this article gives a full rundown of every item in Effective C++ and how it relates to Swift. Note that many of the items are warnings on the dangers of C++, and for the most part these are all avoided in Swift.

### Item 1: View C++ as a federation of languages.

Well, federation is a kinder word than hodgepodge. While Swift has been written from the ground up, so is a lot cleaner, it’s still similar to C++ in that it blends several styles (OO, generic, functional) together in one language, and you should be aware that different styles follow different conventions.

### Items 3: Use const whenver possible

A welcome feature of Swift is the explicit distinction between `let` (const) and `var` (non-const) variable declarations. Using `let` by default, and `var` only when needed, is probably a good policy.

Swift also has the `mutating` modifier that acts like the opposite of C++’s const member function qualifier (i.e. you must specify it if you want to be able to alter internal state, rather than if you are promising not to):

```struct MyStruct {
var val = 0
mutating func touch() -> Int { return ++val }
func look() -> Int { return val }
}

let s = MyStruct()  // s is a constant
s.touch()   // compiler error
```

Sadly, that breaks down with classes, which don’t get to use the mutable keyword, so this compiles just fine:

```class MyClass {
var val: Int = 0
func touch() -> Int { return ++val }
}

struct MyStructWithClassProperty {
var val = MyClass()
}

let s = MyStructWithClassProperty()
s.val.touch()
```

This rules out using this feature to implement const-correct behaviour for more complex types (user-defined container classes, for example). Maybe someday it’ll be extended to cover more cases.

### Item 5: Know what functions C++ silently writes and calls

Swift, like C++, silently writes some class functions for you. For example, if you don’t write an `init()` function for a struct or base class, but you do give all its properties default values, it will write a default initializer for you that takes no parameters. But if you do write another initializer, that takes parameters, you have to write a default one as well.

### Item 12: Copy all parts of an object

Beware the seductive `struct`. It’s a value type, they say. It gets copied when you assign it, they say.

Well, to a point. As we saw in item 3, when you include a class as a property of a struct you leave some of those struct guarantees behind, and copying is one of them. If you were to make two copies of `MyStructWithClassProperty` above, they will both end up pointing at the same instance of MyClass.

Unfortunately, unlike in C++, Swift structs don’t get to implement a copy constructor. When a copy is made, it’s a shallow bitwise copy and the author of the struct has no programmable hooks to find out it’s happening. Instead you have to implement a .copy() method of your own and hope users call it.1 Maybe someday struct copy constructors will be added as a feature.

### Item 13: Use objects to manage resources

Classes in Swift can implement a deinit method, that executes when the class is destroyed after all references to it are deleted. And with ARC, when that happens is a lot more deterministic than it is in Java and garbage collection. Maybe you can get some of that sweet RAII action C++ programmers are so keen on.2 The Apple docs even encourage you to do this, with an example about putting gold coins back in a bank.

But be careful! Try typing the following into a playground:

```class Person {
init() {
println("Object is being initialized")
}
deinit {
println("Object is being deinitialized")
}
}

func deinit_demo() {
var reference1 = Person(name: "John Appleseed")
}
deinit_demo()
```

and watch as you see no deinitialization logged to the console. This is presumably because the playground grabs references to everything to keep them around for playground-purposes. Fair enough, don’t use this pattern in the playground then. But you also need to watch out for the variables being captured by any closures,3 which will keep them around just by touching them, not even needing to assign them to another variable. Remember this if you’re ever trying to debug some mystifyingly resource-leaking code.

“But what about structs?”, you ask. They’re created on the stack, surely they get destroyed as soon as they fall out of scope. Well, sure, except first they can’t have a `deinit` method (again, maybe someday), and second, they can still be captured, so that’s no help.4

And finally, from More Effective C++:

### Item 7: Never overload &&, ||, or ,

Or, in Swift’s case, totally go ahead and overload them, but make sure you do it right.

In C++, overloading `||` is dangerous because of the short-circuiting feature programmers are used to. Suppose you write the following:

```if(cheapOp() || superExpensiveOp()) {
doSomething()
}
```

Say `cheapOp()` returns true. That means the whole `if` statement can never not be true, no matter what `superExpensiveOp()` returns. So what’s the point of executing it? None, so in C, C++, Swift and most other languages with a `||`, it won’t even get executed. If `cheapOp()` is true most of the time, that could give you a big performance benefit.

Except in C++, when you implement your own `||` operator, it’s just a regular old function, and all its parameters are fully evaluated before they are passed

The same would happen in Swift – but Swift has a feature, @auto_closure, that can be used to avoid that problem. Putting @auto_closure before a parameter means that statement gets wrapped in a closure for later execution.

So this:

```if(cheapOp() || superExpensiveOp()) {
doSomething()
}
```

gets rewritten as this:

```if(cheapOp() || { return superExpensiveOp() }) {
doSomething()
}
```

and in your implementation of the || operator you do the following

```func ||(lhs: LogicValue, rhs: @auto_closure () -> LogicValue) -> Bool {
// only if the left-hand side is false...
if(!lhs) {
// ...do you then need to execute the closure that wraps the second half
if(!rhs()) {
return false
}
}
return true
}
```

A lot of people are excited about @auto_closure, as it enables some interesting possibilities – for example, a conditional logger that only executes expensive to-string operations if the log-level is debug, or an implementation of the ruby `||=` assignment-if-nil idiom (read this article for more on that one). One of the reasons I’m excited about Swift is there are probably more of these to come as the language continues to evolve through it’s beta period.

1. You could always talk about this issue as if it’s a deliberate feature of your collection class, like Apple does in the documentation for Swift Arrays.
2. Course, RAII isn’t nearly as useful when there are no exceptions waiting to pounce and pull the rug from under you at any moment, but still.
3. And obviously getting explicitly assigned to another variable, or being passed out of the function, but I assume you realize that.
4. When they are presumably whisked off to heap-land to live with the other reference-counted animals. Is Swift performing some secret autoboxing for this under the hood?

# Using Any to Store Numbers in Swift

In the last post we implemented an accumulator using generics, so it could handle either integers or floating point types.

But how about handling both in the same accumulator? In Paul Graham’s guidelines for submitting an accumulator, he says it needs to work

for any numeric type – i.e. can take both ints and floats and returns functions that can take both ints and floats. (It is not enough simply to convert all input to floats. An accumulator that has only seen integers must return integers.)

He then gives some example usage: 1

E.g. if after the example, you added the following code (in a made-up language):
`x = foo(1);`
`x(5);`
`foo(3);`
`print x(2.3)`
It should print 8.3.

But if you try to do this with our generics implementation, you will get a error when you pass in the final number. “Cannot convert the expression’s type ‘Int’ to type ‘Int’”, the compiler will say, which is a little confusingly worded given it’s a Double that can’t be converted, but what it means is it can’t convert what you passed to it’s Int parameter into an Int.

So I guess our example still isn’t valid for submission. What behaviour do we need? In Ruby, you can do the following:

```irb> n = 1
=> 1
2.1.0 :002 > n.class
=> Fixnum
2.1.0 :003 > n += 2.2
=> 3.2
2.1.0 :005 > n.class
=> Float
```

The value `n` silently gets upgraded to a float. How can we do this in Swift? Well, there is an Any type that can hold any kind of type. But it’s not as easy as that. Just trying the following:

```  func foo(var n: Any) -> (Any) -> Any {
return { n += \$0; return n }
}
```

gets you the familiar compiler error about there being no overloaded += operator. But unlike when we had this problem with generics, this can’t be fixed with type constraints. Any doesn’t implement +=.2 In fact, Any doesn’t let you do much of anything except store a value and pass it around. If you want to maniuplate what’s inside, you must use a switch statement:

```let a: Any = 1
switch a {
case let i as Int:
// do appropriate logic when it's an Int
...
}
```

If we revisit our `incf` implementation, but adapt it to take and return Any, and upgrade an Int to Double by switching to identify them, we get the following monstrocity:

```func incf(inout lhs: Any, rhs: Any) -> Any {
switch lhs {
case let i as Int:
switch rhs {
case let j as Int:
lhs = i + j
case let d as Double:
lhs = Double(i) + d
default:
// what to do here?
}
case let d as Double:
switch rhs {
case let e as Double:
lhs = d + e
case let i as Int:
lhs = d + Double(i)
default:
// what to do here?
}
default:
// what to do here?
}
return lhs
}
```

What to put in for those default cases, where one of the types isn’t supported. Maybe throw an exception? Hahaha only kidding, Swift doesn’t have exceptions.3 The Swift way of handling this would be to allow incf to return a nil type.4 Users of `foo` then have to account for the possibility of an error. Let’s do that, and add an implementation of `foo` with our new `incf`:

```func incf(inout lhs: Any, rhs: Any) -> Any? {
switch lhs {
case let i as Int:
switch rhs {
case let j as Int:
lhs = i + j
case let d as Double:
lhs = Double(i) + d
default:
lhs = nil
}
case let d as Double:
switch rhs {
case let e as Double:
lhs = d + e
case let i as Int:
lhs = d + Double(i)
default:
lhs = nil
}
default:
lhs = nil
}
return lhs
}

func foo(var n: Any) -> (Any) -> Any? {
return { incf(&n, \$0) }
}
```

There are many flaws in this approach, but it does at least work with the example above now – pass an Int and then a Double and you’ll get a Double.

Pass a Float in though and you get back a nil. But adding Float to the already nasty switch statement will make it even nastier. If we wanted to extend incf to cover even more types (maybe numeric classes like a Rational or Decimal) it gets even worse. And if we want to implement a decrement function we’d have to replicate the whole statement.

There’s one more way to write the switch statement. Swift’s pattern matching can operate on multiple values together, giving us the following alternative to having to nest multiple switch statements:

```func incf(inout lhs: Any, rhs: Any) -> Any? {
switch (lhs,rhs) {
case let (i as Int, j as Int):
lhs = i + j
case let (d as Double, e as Double):
lhs = d + e
case let (i as Int, d as Double):
lhs = Double(i) + d
case let (d as Double, i as Int):
lhs = Double(i) + d
default:
lhs = nil
}
return lhs
}
```

Unfortunately, while this code is a little more succinct, and possibly less error-prone, it still suffers from the same problems if you tried to extend it to more types.

The next post will be about ditching `Any` in favor of a more type-safe approach to this problem.

1. Note, he calls foo a second time in his example. Presumably he got a lot of duff submissions where people were using global variables to accumulate.
2. And before you try it, no, you can’t extend Any to try and implement `+=`. Or anything else for that matter, it’s unextendable.
3. This is a good example of how removing exceptions forces you to find a perfectly valid alternative in many cases. Exceptions were always discouraged in Objective-C except for truly exceptional circumstances, Swift took this one step further and did away with them entirely.
4. If you think the right thing to do is not add the number, you’ll hit a different problem. That means the default action should do nothing, but Swift insists you have some code there. So you have to write something that doesn’t have any effect. Feel free to get creative. No, I’m afraid a comment saying “do nothing” doesn’t count as something.

# An Accumulator in Swift, Part 2 – Using Generics

In Part 1 of this post, we wrote an implementation of Paul Graham’s accumulator problem in Swift. Here’s one of the versions:

```func foo(var n: Int) -> (Int) -> Int {
return { n += \$0; return n }
}
```

This looks pretty similar to the Ruby version he gives:

```def foo (n)
lambda {|i| n += i }
end
```

Except there’s a problem. On his page of guidelines for submitting an example in a new language1 he points out it needs to:

[work] for any numeric type – i.e. can take both ints and floats and returns functions that can take both ints and floats. (It is not enough simply to convert all input to floats. An accumulator that has only seen integers must return integers.)2

In Ruby, this isn’t an issue because of the duck typing. But in Swift, if you try to pass a Float to `foo`, you’ll get an error. We’re going to have to use another feature to fix this – generics.3

First let’s try implementing incf using generics, so it can take an `Int` or a `Float`. We do this by defining a type parameter T in angle brackets after the function name, and then using that instead of the explicit `Int`s:

```func foo<T>(var n: T) -> (T) -> T {
return { n += \$0; return n }
}
```

Oops, more compiler errors. “Could not find an overload for ‘+=’ that accepts the supplied arguments” again.

This is because not all objects have a `+=` operator, so if you tried to use it with one of those, it wouldn’t work. Unlike in C++ templates, where you wouldn’t get a compiler error4 unless you tried to use `incf` with a type that was missing a `+=`, Swift requires you to restrict your types up-front.

The way you ensure a type will support the necessary member functions is by using Type Constraints. These are protocols you append to your generic type. For example, if you wanted to write a generic less_than function, you could use the Comparable type:

```func less_than<T: Comparable>(lhs: T, rhs: T) -> Bool {
return lhs < rhs
}
```

Only classes that implement the Comparable protocol can be used with the `less_than` function, and because they impelement this protocol they’re guaranteed to have a < operator.

The Swift standard library only defines 3 protols so far – Equatable, Comparable and Printable.5 They don't cover what we need, so we'll define our own. Let's call it, uhmm, Addable.

```protocol Addable {
@assignment func += (inout left: Self, right: Self)
}
```

Then, we need to declare that Int and Float support Addable by extending them with the new protocol:

```  extension Int: Addable { }
```

Finally, let's try our generic function with the new constraint:

```func foo<T: Addable>(var n: T) -> (T) -> T {
return { n += \$0; return n }
}
```

Now, if you pass in a Float to `foo`, it works.6. In fact, if you tag any type that implements `+=` it will work for that type too. Try it with String.

Anyway, with this requirement covered, hopefully we can add Swift to the pantheon of powerful languages. Maybe one day they'll take new submissions to the page!

1. These pages tell a story. First he was all hey guys, let’s get all the examples, this is cool! Then he’s like, no you numbskulls, read the problem, that’s not what it says! Eventually he gives up and tells people to stop emailing him.
2. Strictly speaking what we’ll implement still doesn’t cover this requirement, because the quote and the example following it implies it needs to be able to switch dynamically between integers and floating point halfway through. Read the next part for a solution to this.
3. I love generics. But then the first language they taught me in college was Ada, and after that I spent years in the C++ mines, so it’s not surprising.
4. The compiler error will be about 10 lines long and will fill you with hopeless despair. Concepts, something similar to Swift’s protocol constraints, didn’t make it into C++11.
5. They don't define Assignable. I guess that's considered so fundamental you can take it as a given. Presumably they're going to add a lot more standard protocols to the library over time, so keep an eye on that page. There are several more implemented but not yet documented – to see them, type `import Swift` into playground, and command-click it.
6. I was pretty amazed when it did the first time I tried this.

# An Accumulator in Swift

In an appendix to his article Revenge of the Nerds, Paul Graham suggests a problem to solve in a programming language to see how “powerful” that language is.1

The problem: Write a function foo that takes a number n and returns a function that takes a number i, and returns n incremented by i.

Also note,

(That’s incremented by, not plus. An accumulator has to accumulate.)

Solving this problem is one of the first things I try when learning a new language. This article will implement various versions this function in Swift, as a way to explore some of Swift’s features.

Here’s a first attempt. It’s very similar to the `makeIncremetor` function in the Closure section of the Apple Swift book, except adapted to match Graham’s definition of the problem:2

```func foo(n: Int) -> (Int) -> Int {
var acc = n
func inc(i: Int) -> Int {
acc += i
return acc
}
return inc
}
```

Read that first line defining `foo` as: it takes a parameter, `n`, and returns a function, which itself takes an `Int` as a parameter and returns an `Int`.3

That returned function is a closure – a self-contained combination of a function and an environment of variables (in this case, just one, `acc`). Each time you then call that returned function, it adds the value `i` you pass in to `acc` to keep a running total, and then returns the latest total.

In case you’re not familiar with closures, here’s a short explanation of what’s happening.4 When declared, the function `inc` “captures” the outer variable `acc`, so instead of `acc` being destroyed when it falls out of scope, it sticks around and continues to be useable by the `inc` function. Note that if you call `foo` again, it creates a brand new `inc` function/`acc` variable pairing, starting from whatever `n` you just passed in. Think of this as similar to creating a new instance of a class with a member variable acc, initialized with `n`.

So, people have been enjoying comparing swift to other languages. I like Ruby, so let’s take the Ruby example from Graham’s list of canonical solutions to his problem.

```def foo (n)
lambda {|i| n += i }
end
```

Well that’s a lot more compact!5 Let’s look at why, and get our Swift example closer.

The Ruby example just captures and uses the input parameter `n` for its state variable. We can do this in Swift too, with the addition of the var keyword in front to allow it to vary (without those changes affecting the caller’s passed-in variable):

```func foo(var n: Int) -> (Int) -> Int {
func inc(i: Int) -> Int {
n += i
return n
}
return inc
}
```

Next, the inner function is anonymous, and returned directly. We can do that in Swift too. Unlike in Ruby, we don’t need to use a lambda keyword to declare an anonymous function:

```func foo(var n: Int) -> (Int) -> Int {
return { (i: Int) -> Int in
n += i
return n
}
}
```

Now let’s look at all those type declarations cluttering up the place. Ruby doesn’t have them because it is duck typed. Swift on the other hand is strongly typed.6 But there is hope – some of them can be eliminated by Swift’s type inference. In the inner function, we already know the types of everything being passed in or returned, so we can leave them off and the compiler infers them from the context:

```func foo(var n: Int) -> (Int) -> Int {
return { i in n += i; return n }
}
```

Do we still need the declaration of `i`? If the types can be deduced, you can use `\$0`, `\$1` etc for the arguments, and skip the `in`.

```func foo(var n: Int) -> (Int) -> Int {
return { n += \$0; return n }
}
```

Finally, so long as a closure is just a single expression, you don’t need an explicit return – the result of the expression is automatically returned. This leaves us with something very similar to Ruby, where the last statement is always returned (in Ruby’s case, even with multi-line functions).

```func foo(var n: Int) -> (Int) -> Int {
return { n += \$0 }
}
```

Except oops, no, that last one won’t compile. “Could not find an overload for ‘+=’ that accepts the supplied arguments” it says. That’s a little confusing, because the “argument” in question is actually the return type. In Swift, `+=` doesn’t return a value7 (unlike in Ruby where almost every statement has a value8 and can be used on the right-hand side, even an if statement).

If you were thinking, I know, let’s override `+=` to return a value, nope Swift won’t let you do that.9 Also, you’re the reason I hate other people’s code. To get inspiration for an alternative function, let’s look at the lisp example from the canonical list:

```(defun foo (n)
(lambda (i) (incf n i)))
```

And here is an implementation of that function:

```func incf(inout lhs: Int, rhs: Int) -> Int {
lhs += rhs
return lhs
}
```

Note the use of the `inout` keyword to indicate that the changes made to this parameter affect the variable passed in by the caller, unlike with `var`.

Since our new function returns a result, we can now use it to implement a single-expression closure:10

```func foo(var n: Int) -> (Int) -> Int {
return { incf(&n, \$0) }
}
```

Swift requires you to put an & in front variable when passing in an `inout` parameter, which is nice as it means you can’t accidentally miss the possibility of side-effects.

That’s probably as far as we can go. It’s pretty similar to the Ruby version at this point. Except… we didn’t quite solve the stated problem. To find out why, read on to Part 2 of this article.

1. If you take issue with this as a measure of language power, take it up with Mr Graham.#160;
2. If you’re eyeing `foo` suspiciously, and wondering why it isn’t called, say, `makeAccumulator`, I agree with you.
3. I’m not wild about the Swift syntax for type definitions of functions returned from functions. I know it’s completely unambiguous if you read it from left to right but it makes me nervous when I look at it. I don’t have any better proposals, either.
4. Those who are familiar – please be gentle with me and my explanation!
5. Note I said compact, not neater or cleaner or more expressive. But I happen to think it’s those things too.
6. Terms like strong or duck typing are not rigorously defined, but people can get very emotional about it when they think they’re being used incorrectly. Please email Casey.
7. I do wonder why they decided to not have assignment return the value of the left-hand side. Seems like this is a legit use case. I guess maybe they they thought it was too side-effecty to change a value while also using it? But if you’re going to do that, go all the way and ban `++i` from being used on the right-hand side of expressions – but that would probably lead to the C guys assaulting the castle with torches and pitchforks.
8. That’s right, almost everything. Not everything. Grrr. Though, otherwise, I really like this language feature.
9. Interestingly, it will allow you define `+=` return a value when you write it for your own classes. This is probably not a good idea.
10. Yes I’m aware writing a two-line function just to compact less code elsewhere is a bit silly, but give me a break, we’re just experimenting here. Plus I think the lisp “build up the language to meet your problem” thing is a nice idea.