In Swift, we can make most types decodable by adding the Decodable protocol. While Swift’s default decoding is sufficient in most cases, it leads to issues if simple enumerations are extended later on.

This article demonstrates different approaches how to work around this issue, and highlights the advantages and disadvantages of each approach.

The Problem

Let’s say we are working on an app that allows you to book and pay for different modes of transportation, and we would like to configure from the backend which transport modes and payment methods are shown, and in which order.

We could have an enum for the transport modes, and one for the payment methods:

The app config we get from the backend could then include two arrays of these enums:

To reduce the noise in the upcoming examples, we introduce a helper method to decode a string containing JSON to a given type:

Let’s make sure everything works as expected:

In new versions of the app, we could add new cases to the enums. We may extend the supported transport modes with a case rideHailing, and/or the payment methods with a case sepa. If our backend sends the new cases to the old version, decoding of the app config will fail:

We could make sure our backend does only send the new values to the newer clients, still that’s a risk: accidentally sending a payload with just one unexpected value for any of the enums will break the decoding of the whole app config. This is different to adding additional keys in the JSON object, which are ignored in decoding.

Let’s explore options on how to work around the issue. The goal is to skip unknown enum cases when decoding.

Solutions Using Custom Decoding

When we add Decodable to a type, we get a default implementation of the decoding initializer, that is a method with the signature init(from decoder: Decoder) throws .

Custom Decoding Initializer

Providing our own decoding initializer gives us complete control over how decoding is handled. Inside the initializer, we first decode our enums to arrays of the underlying raw value type, then use compactMap to get rid of any values for which we have no mapping in our enums. To implement this custom decoding, we have to provide an enum for the coding keys as well:

Decoding now skips the unknown enum cases like we wanted:

The disadvantage of this solution is that whenever we add properties to the app config, we have to change it in two places now: add the property to CodingKeys, and decode it by hand in init.

Parse underlying Raw Values and Compute the Arrays

Instead of defining a custom decoder, we can use the CodingKeys to map the arrays to private properties with the respective underlying raw value type, then compute the enum array properties based on the private properties:

Decoding gives us the same results as before:

The solution is quite straightforward, and we don’t need a custom initializer anymore. We still have to declare the CodingKeys though, so when adding new properties to the app config, we need to add these to the coding keys. Also, the properties are computed which carries a performance penalty, and forces us to declare them with var instead of let .

We could work around the repeated computation by using lazy properties:

But then accessing the lazy properties mutates the struct, so when accessing the properties, the decoded app config itself needs to be declared with var instead of let:

All approaches we saw so far share the disadvantage of duplicating the logic for mapping the enums. Let’s explore solutions on the property level.

Solutions on Property Level

We want the properties with the enum arrays to be decoded differently to the default behavior. To achieve that, we can use a custom type as the property, instead of using an array directly.

Wrap the Property in a Custom Type

We put the logic for skipping unknown cases in a custom decoding initializer for our wrapper type:

In the app config, we use our custom wrapper type instead of arrays:

After decoding, we now need to access the values property of our custom type:

Compared to the solutions before, there are a couple of advantages: We don’t have to define CodingKeys or a custom initializer on the app config, so when adding properties to the app config we don’t need additional code changes. Also, we removed the duplicated logic of ignoring the unknown values — there is only one compactMap instead of two. We can reuse this wrapper type wherever we like.

One disadvantage is the wrapper type bleeds out to all usages of the properties: Instead of appConfig.transportModes or appConfig.paymentMethods, we have to use appConfig.transportModes.values or appConfig.paymentMethods.values.

Use a Property Wrapper

In newer versions of Swift, we can declare a property wrapper instead.

Note there is not much change to the struct we had before — we add @propertyWrapper, and rename the variable containing the value to wrappedValue.

The types of the properties are back to being arrays of enums:

Accessing the decoded properties works directly again, no more .values:

A slight drawback is we have to declare the properties asvar, as properties using property wrappers cannot be declared as let.

Solutions on Type Level

The previous two solutions handled the skipping of unknown values at the property level. It may be more practical to skip on the type level though: Whenever we declare a property of type [TransportMode] or [PaymentMethod] in a decodable type, we may want to get the skipping of unknown cases for free, without having to use a property wrapper each time.

Extend KeyedDecodingContainer

To change the decoding behavior for decoding a type for a key, we can extend KeyedDecodingContainer. That type makes the encoded properties of a decodable type accessible by keys.

Among other methods KeyedDecodingContainer has methods of the signature decode(_, forKey: _). If we add overloads of this signature for more special types than are covered by the existing decode methods, they will be used in generated decoding initializers.

To not interfere with the code of the other examples, we define the extension for new types TransportMode5, PaymentMethod5, and AppConfig5:

We add two extensions, one for each enum array type:

And let’s make sure decoding succeeds:

When the decoding initializer for AppConfig5 is generated, our two customedecode methods are used as they define how to decode the types [TransportMode5] and [PaymentMethod5].

A disadvantage is we ended up with code duplication again. Also, there is no indication—neither on the properties nor on the types—that arrays of transport modes and payment methods are handled in a non-default way.

Make the KeyedDecodingContainer Extension Reusable

Let’s make the extension reusable. First, we declare a protocol to mark the types for which we want to skip unknown cases in array decoding. We only allow the protocol to be added on types that fulfill our current requirements: We want a type that conforms to both RawRepresentable and Decodable, and the raw value needs to be decodable as well:

Then, we extend KeyedDecodingContainer with a decode method that applies only to arrays of types conforming to our protocol:

Now, all we have to do is to let the types conform to our protocol.

And unknown enum cases are skipped again when decoding:

Which Solution to Prefer?

We saw six approaches on how to solve the issue. Which one should we prefer? I think there are a few we can rule out as candidates:

• Custom decoding (solutions 1+2) forces us to write extra code when adding properties to the app config.
• Of solutions on the property level (solution 3+4), I prefer the property wrapper: while it needs the change from let to var, it does not influence how call sites look.
• Of the solutions on type level with KeyedDecodingContainer (solutions 5+6), I prefer making the extension reusable: it has no code duplication, and the protocol at least gives a hint that the type is handled in a special way.

Two solutions remain: on property level using a property wrapper (solution 4), and on type level using a marker protocol (solution 6).

I like the marker protocol solution because it declares our intent on the type: if we have multiple places where an array of a certain enum is returned, we only need one declaration on the type, and not use the property wrapper multiple times. So no duplication. On the other hand, we may want the duplication in this case: the changed decoding is explicitly visible on the property itself.

If I would have to decide for one winner, I would go for the property wrapper, but the marker protocol is a close second.

Whichever solution you prefer in your code, if you end up needing more and more of workarounds for Swift’s default decoding, there are libraries out there which may help. One example is AirBnB’s ResilientDecoding, others are just an internet search away.

Bonus Track: Increase Reusability of the Marker Protocol Solution

Still here? Good! You may have noticed we had to add an awful lot of constraints on the SkipUnknownCasesInArrayDecoding protocol. Wouldn’t it be nice if we could apply it to any decodable type?

Turns out this is possible. We can use the nestedUnkeyedContainer(forKey:) method to get a data structure that allows us to go through all elements in the array. We collect all elements where the decoding succeeds in a result array. The elements where decoding fails we skip by decoding them to an empty struct — there decoding always succeeds:

And that’s it for the bonus track. Happy Decoding!

Safely Decoding Enums in Swift was originally published in Mobimeo Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

Baseline alignment still goes strong today: On the web, CSS allows baseline alignment; on Android, baseline alignment is part of Material Design.

📱What about iOS?

Baseline alignment is not the default on iOS: A label takes the space needed for the content, the baselines do not lie on an invisible grid.

At one point, we were asked by our designers whether it would be possible to do baseline alignment on iOS. Let’s concentrate on UILabel, as that is used to display text in most cases.

What complicates things is Dynamic Text. If an app uses that for accessibility, the designers have a choice of eleven predefined text styles (like headline, caption, …). The sizes of these text styles are not fixed, but change based on the user’s choice of the content size category. There are twelve content size categories: seven ranging from XS to XXL, and five even larger sizes for accessibility.

🥅 Goal

The goal of this article is to give an idea how to achieve baseline alignment for UILabel, working for Dynamic Type (that means all 11 * 12 = 132 combinations), and for multi-line labels.

📕 Terminology

First, let’s align on the terminology how we use it in this article.

• The baseline is the imaginary line on which the characters rest.
• The ascender is the offset from the baseline to the font’s longest ascender, the topmost point of any character, including space for accents/umlauts.

• The descender is the offset from the baseline to the font’s longest descender.
• The line height is the height of a line of text, that is the ascender plus the descender.
• The leading is the extra distance between two lines of text. It is pronounced “ledding” and not “leeding”, as in hand typesetting it was done with strips of the metal lead.

😕 A Bit of Confusion

Some of the terminology is not used consistently.

• While the ascender for the fonts used in Dynamic Text includes space for accents and umlauts, it is often shown smaller in illustrations (Font handling, Apple Developer docs)
• The line height is often shown including the leading, but it does not include the leading on iOS (Font handling, Apple Developer docs)
• The leading is the extra distance between two lines of text, but sometimes (mainly in electronic typesetting) it is used to describe the full distance between two lines of text instead (Visual design typography, Apple Developer docs)

🔎 Implementation Details

Let’s see how to approach this in code.

🧱 Setup

We want to make sure our assumptions hold for all dynamic type fonts. There are 12 content size categories a user can choose.

We can use 11 different text styles for dynamic type.

With 12 content size categories and 11 text styles, we end up with 132 combinations for which we have to check everything works fine. Let’s build an array of those fonts.

To see whether the height of a label matches our expectations, we add a helper method to give us the height of a label for a given font, number of lines, and an optional line spacing:

As our goal is to place something on a grid, let’s add a helper method to have an easy way to round up a number to the next multiple of a given unit:

📐 Validate Assumptions on Font Metrics

The ascender is always a positive value:

The descender is always a negative value (as it goes in the opposite direction from the baseline in comparison to the ascender):

The line height is always the sum of the ascender and the negated descender:

☝️ Validate Assumptions for Single Line Labels

Contrary to what we may expect at first, the height of a label of a single line of text is not always equal to the line height of the font:

To get the height of the label, we have to round up the line height to the next “pixel”:

🎯 Reaching the Goal for Single Line Labels

In iOS’ Auto Layout, we can anchor to the first and the last baseline of a label via firstBaselineAnchor/lastBaselineAnchor. Except for a tiny bit of rounding up, the single line label has the same height as the line height.

If we have a top anchor that is on the grid, we can add a constraint that sets the first baseline of the label to that anchor plus the ascender rounded up to the grid size. That way, the baseline ends up on the grid, and as we rounded the ascender up, there is enough space for the ascender:

If we have a bottom anchor that should end up on the grid, we can add a constraint that sets the last baseline of the label plus the (negated) descender rounded up to the grid size to that anchor.

So now if the top anchor is on the grid, the two constants fix the baseline and the bottom anchor to the grid. This solves the issue for single line labels. For multi-line labels, we additionally need to make sure that the distance between two baselines is a multiple of the grid unit.

🖐 Validate Assumptions for Multi Line Labels

The multiple of the line height rounded up to the next pixel is not always the label height.

To calculate the correct height, we have to take the leading into account:

The distance between two baselines is font.lineHeight + font.leading. To get a grid alignment for multi-line labels, we need to round that distance up to a multiple of the grid. So how can we add to the distance between two lines? lineSpacing in an attributed text’s paragraph style sounds right.

Unfortunately it’s not that easy. Here is a test adding 1.5 to the line spacing of a two-line label. There are cases where the calculation is off:

The calculation only works if the leading is less than or equal to zero:

If the leading is positive, it turns out it is used as a minimum line spacing for dynamic type fonts! This is an inconsistency between the handling of negative and positive leadings. Examples:

• Leading -0.5 points, lineSpacing 1.5 points: 1 point between the lines
• Leading +0.5 points, lineSpacing 1.5 points: 1.5 points between the lines
• Leading +2 points, lineSpacing 1.5 points: 2 points between the lines

To increase the line height correctly for positive leadings, we have to add positive leadings to the line spacing.

Now we have figured out how to reliably increase the distance between two baselines. What’s left is to set that increase to the distance between two baselines is a multiple of the grid unit.

🎯 Reaching the Goal for Multi Line Labels

For a label, the default distance between the baselines is the line height plus the leading.

Our target distance between baselines is the default distance rounded up to the next multiple of the grid unit. As the constraints from the single line label handling above guarantee the first baseline to be on the grid, all the following lines will then be on the grid as well.

The line spacing we have to set is the difference between the two.

But as positive leadings act as minimum line spacing, we have to add those to the line spacing.

Now we can use this line spacing in a paragraph style, and instead of setting the text on the label, set the attributed text with that paragraph style.

🛠 Putting It All Together

The outcome of this experiment is that aligning to a baseline grid on iOS is possible.

You can find a playground with the code shown in this article, as well as a sample app with an implementation of a label view that aligns the text on the baselines hosted on GitHub here: https://github.com/mobimeo/ios-baseline-alignment. For production code, you should consider converting the assertions into unit tests, so if the behavior changes in future versions of iOS, you learn about it early enough.

The biggest learning for me was the different handling of leading for positive and negative values. Or maybe that I pronounced leading wrong for way too long. 😅

What If Your Designers Want a Baseline Grid on iOS? was originally published in Mobimeo Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s an Operator?

Most programming languages use operators. Simply put, an operator is a symbol or phrase that represents a functionality. For example, i = 1 in Swift uses the assignment operator = which has the functionality of storing the value 1 in the variable i. Many languages also have phrases that are operators, like sizeof in C, and the type-cast operator as in Swift.

Arity

An operator, or more accurately the operation represented by an operator, accepts a number of operands (parameters in operator lingo). The number of operands an operator accepts is called the arity. From Objective-C, we know operators with arity 1–3.

Unary operators represent operations with one operand. Examples in Objective-C include the negation operator !, the increment operator ++, and the sizeof operator.

Binary operators represent operations with two operands. The majority of Objective-C’s operators are binary operators, like +, -, *, /, <, <=, >=, >, ==, !=, &&, =, +=, -=, and so on.

Ternary operators represent operations with three operands. In Objective-C and Swift, there is only one ternary operator: The conditional expression ? : . As it’s the only ternary operator in both languages, and as we can’t customize it, let’s focus on unary and binary operators from now on.

Placement

An operator can be placed in three ways relative to its operands. An unary operator can be placed on either side of the operand: Either as a prefix, like the negation operator in !visible, or as a postfix, like the increment operator in i++.

Binary operators could be placed as a prefix, postfix, or infix (between the operands). In Objective-C and Swift, binary operators are always placed infix. As we focus on unary and binary operators, the placement (also called fixity) of an operator is sufficient to determine the arity: Prefix and postfix operators are unary, infix operators are binary.

Overloading

Operators are often overloaded, meaning they work for different types. In C/Objective-C for instance, the + operator is overloaded to allow adding two int and two double, among others. In contrast, functions in C/Objective-C are never overloaded. To be fair, the C11 standard introduced a _Generic keyword which allows us to at least write a macro that emulates function overloading.

Precedence and Associativity

Operators have a precedence, and an associativity that determine the order in which they are executed.

let a = 3
let b = 4
let c = a * a + b * b
let d = b — a + b

Swift follows the rules we are used to from math. Multiplication has a higher precedence than addition. So the first calculation results in c = (a * a) + (b * b) = 25. Addition and subtraction have the same precedence, and left associativity. So the calculation is grouped from left to right, and results in d = (b - a) + b = 5.

Operators can either be left-associative, right-associative, or non-associative. You may wonder how non-associativity may be a good thing. Here is an example:

BOOL a = NO;
BOOL b = NO;
BOOL c = YES;
if (a == b == c) {
    NSLog(@"WAT");
}

At first glance, we may expect this code to only print “WAT” if and only if a, b, and c are equal. However, == is left-associative in Objective-C, so a == b == c means (a == b) == c, which is true for a couple of combinations.

In Swift, == is non-associate, so the compiler will gives us a shiny error that a non-associative operator is adjacent to an operator of the same precedence.

var a = false
var b = false
var c = true
if a == b == c {     // COMPILER ERROR
    println("WAT")
}

I like it when a language keeps me from making stupid mistakes.

Short-Circuit Evaluation

A couple of operators in Objective-C and Swift provide short-circuit evaluation. That means an operand is only calculated if necessary. The following code will not print anything, as the result of the logical && operator is already determined by the first operand.

func foo() -> Bool {
    println("foo() called")
    return true
}
false && foo()

Now that we have the terminology straight (unary, binary, prefix, postfix, infix, precedence, associativity, short-circuit evaluation), let’s see how we add operators in Swift.

Adding Operators in Swift

Objective-C does not allow us to add operators: They are hard-coded in the language. In Swift, we can define a surprisingly rich set of operators. We can use most combinations of the ASCII symbols ., +, -, *, /, %, <, =, >, !, &, |, ^, ~. Even better, we can use a plethora of Unicode characters. Math. Arrows. Symbols. Dingbats. And more. And if that’s not enough, we can use Unicode combining characters on those characters as well.

Let’s add the operators logical negation ¬, logical conjunction ∧, and logical disjunction ∨ as alternatives to !, &&, and ||.

Operator Declaration

Adding a new operator consists of two parts: We have to declare the operator, and to implement at least one function giving meaning to the operator. The logic operator ¬ is a prefix operator:

prefix operator ¬ {}

Associativity and precendence declarations go between the braces. Unary operators in Swift always take precedence over binary operators, so we aren’t allowed to specify any precedence. We are also not allowed to specify an associativity, as unary operators always cling to their operand. As a result, whenever we add a prefix or postfix operator, the braces remain empty — but they have to be there.

Operator Implementation

Next, we implement a function for the operator. The function name is simply the operator symbol. We have to put prefix in front of the function declaration, so the compiler knows which function to use even if we would later declare a postfix version of the operator as well (think ++i vs i++).

prefix func ¬(a: Bool) -> Bool {
    return !a
}

That’s it! Our new operator is ready for use:

assert(¬false)
assert(¬(¬true))

Infix Operators

Next up: The ∧ operator. A first attempt by copy-pasting and adapting the ¬ operator may look like this:

infix operator ∧ {}
infix func ∧(lhs: Bool, rhs: Bool) -> Bool { // COMPILER ERROR
    return lhs && rhs
}

The compiler complains that the infix modifier is not required or allowed on function declarations. OK, let’s delete it. Then the code works — as long as we don’t try to use the operator in an expression more than once.

assert(true ∧ true)
assert(¬(true ∧ false))
assert(true ∧ true ∧ true) // COMPILER ERROR

Choosing an Associativity

That’s because for infix operators, the default associativity is none. The && operator for which our operator will be an alternative is left associative. So we declare our operator to be left associative as well, and the error goes away.

infix operator ∧ { associativity left }

Adding Short-Circuit Evaluation

Now let’s add short-circuit evaluation. The following code should not print anything.

func foo() -> Bool {
    println(“foo() called”)
    return true
}
false ∧ foo()

But of course it does: false ∧ foo() differs to a function call syntactically, but is the same semantically. We can even write down the function call:

(∧)(false, foo())

The parentheses around the operator symbol are needed as ∧(false, foo()) would be parsed as using a prefix operator ∧ with the operand (false, foo()).

All arguments of a function call are evaluated before the call takes place. How can we delay the evaluation of the second parameter? We could make the second parameter a closure returning a Bool. If you don’t know what a closure is, think “anonymous function” or “Objective-C block-like thingy”, both are close enough to understand what’s going on.

func ∧(lhs: Bool, rhs: () -> Bool) -> Bool {
    return lhs && rhs()
}

func foo() -> Bool {
    println(“foo() called”)
    return true
}
false ∧ { foo() }
(^)(false, { foo() })

Now rhs() will only be evaluated if lhs is true, because of the short-circuit evaluation of &&. But this comes at a price: We have to put the second argument in braces ourselves now to make it a closure. What we need is something that automatically wraps the second parameter in a closure. In Swift, that can be done by using the @autoclosure attribute on the parameter. Now we get real short-circuit evaluation, without having to wrap the second argument in braces.

func ∧(lhs: Bool, rhs: @autoclosure () -> Bool) -> Bool {
    return lhs && rhs()
}

func foo() -> Bool {
    println(“foo() called”)
    return true
}
false ∧ foo()
(^)(false, foo())

Allow me to get sidetracked here for a bit. As the last line of the example above demonstrates, the autoclosure attribute is not limited to operators syntax, but works just fine for function calls as well. One example that relies heavily on @autoclosure is Swift’s assert function.

var error: NSError? = nil
assert(error == nil, "error is \(error!.localizedDescription)")

The assert call above gets a condition, and a message as arguments. If the message argument in the above example would be always evaluated, the code would crash: We force-unwrap error, which is nil. However, assert uses the autoclosure attribute on the message parameter, and only evaluates the closure if the condition evaluates to false. So we can safely use the force-unwrap in the second parameter, even though error is nil!

On the condition parameter of assert, the autoclosure attribute is also used. That way if we disable assertions, the condition parts stay unevaluated as well, and a compiler optimization can remove them completely.

The beauty of that is although assert has all these features, it can still be implemented as a Swift function! Compare that to C, where assert was implemented as a preprocessor macro, or to Java, where assert had to be added as a keyword. Swift’s autoclosure attribute allows us to write functions and operators that would require compiler changes in a couple of other languages.

Back to our topic: custom operators. As we just implemented the logical conjunction ∧ , the logical disjunction ∨ is a breeze:

infix operator ∨ { associativity left }
func ∨(lhs: Bool, rhs: @autoclosure () -> Bool) -> Bool {
    return lhs || rhs()
}

The only problem that’s left is that we can get wrong behavior when combining our two infix operators.

assert(true || true && false)  // OK
assert(true ∨ true ∧ false)  // FAIL

Adding Precedences

That’s because we haven’t declared precedences yet. Both operators share the same (default) precedence, and both are left associative, so the expression is evaluated as (true ∨ true) ∧ false. But of course we want the ∧ operator to have higher precedence, so that we end up with true ∨ (true ∧ false).

In Swift, precedences are declared as numeric values from 0 to 255. Unsurprisingly, a higher value means a higher precedence. The default precedence is 100. As we want our operators ∨ and ∧ to be alternatives to || and &&, we look up the the precedence values of those two, and use the same values for our operators:

infix operator ∧ { associativity left precedence 120 }
infix operator ∨ { associativity left precedence 110 }

And that’s it. We have added three new operators to the language, using only a couple of lines of code:

prefix operator ¬ {}
prefix func ¬(a: Bool) -> Bool {
    return !a
}

infix operator ∧ { associativity left precedence 120 }
func ∧(lhs: Bool, rhs: @autoclosure () -> Bool) -> Bool {
    return lhs && rhs()
}

infix operator ∨ { associativity left precedence 110 }
func ∨(lhs: Bool, rhs: @autoclosure () -> Bool) -> Bool {
    return lhs || rhs()
}

What about operators that change the operands, like assignment operators, or a swap operator? Lets add an operator <-> that swaps two Int values.

infix operator <-> {}
func <->(inout lhs: Int, inout rhs: Int) {
    (lhs, rhs) = (rhs, lhs)
}
 
var a = 42
var b = 23
 
a <-> b
assert(a == 23 && b == 42)

You may wonder why this works. The function has inout parameters. Shouldn’t we need to use inout expressions, that is prefix the operands with ampersands? We can do that, but we don’t need to: While Swift requires the ampersands for function call syntax, it does not require them if we use operator syntax!

a <-> b        // Totally fine.
a <-> &b       // Works as well. Don't do it though.
&a <-> b       // Works as well. Don't do it though.
&a <-> &b      // Works as well. Don't do it though.
 
(<->)(&a, &b)  // Function call requires & for inout parameters.
(<->)(a, &b)   // COMPILER ERROR
(<->)(&a, b)  // COMPILER ERROR
(<->)(a, b)  // COMPILER ERROR

Overloading Operators in Swift

After we’ve seen how to add operators in Swift, let’s see how we overload existing operators with new functionality. To understand how this works, let’s first have a look at function overloading.

Function Overloading in Swift

In Swift, we can overload a function. That means we give it the same name as another function, but the parameters types, or the return type has to be different. The compiler then tries to infer which function we would like to use.

func foo(i: Int) {
    println("foo(i: Int)")
}
 
func foo(i: String) {
    println("foo(i: String)")
}
 
foo(42)            // -> "foo(i: Int)"
foo("The answer") // -> "foo(i: String)"

When the function to be called is ambiguous, we get a compiler error.

func foo() -> Int {
    return 42
}
 
func foo() -> String {
    return "The answer"
}
 
let result = foo() // COMPILER ERROR

In the code snippet above, foo() is ambiguous: Both functions are equally well suited candidates. To resolve the ambiguity, we can help the compiler in different ways. We can select the function with a cast:

let result = (foo as () -> Int)()

That’s not really pretty. A more readable variant is to make the compiler infer the function by casting the result type:

let result = foo() as Int

In my opinion, the best way in this case is to give the receiving variable the correct type:

let result: Int = foo()

Not only is this the shortest variant, but it clearly states what we want: We want to get an Int result from foo().

If you are used to Objective-C, note that the selection of the function is done statically, not dynamically at runtime.

class A {}
class B: A {}
 
func foo(a: A) {
    println("A")
}
 
func foo(b: B) {
    println("B")
}
 
var a: A = B()
foo(a)           // Prints "A", not "B"!

Although the object a is an instance of B at runtime, the selection of the function is made at compile-time based on the type of the variable a.

Operator Overloading in Swift

Just as we can overload functions, we can implement functions for Swift’s operators to achieve operator overloading. We can overload almost any operator. Swift only reserves a couple of operators to prevent changing fundamentals of the language. For instance, we can’t overload the assignment operator =.

Let’s overload the + operator so that it works as a union for NSSet.

func +(lhs: NSSet, rhs: NSSet) -> NSSet {
    return lhs.setByAddingObjectsFromSet(rhs)
}
 
var x = NSSet(objects: "a", "b")
let y = NSSet(objects: "b", "c")
let z = NSSet(objects: "a", "b", "c")
assert(x + y == z)

While we’re at it, we overload the += operator to match our new + operator:

func +=(inout lhs: NSSet, rhs: NSSet) {
    lhs = lhs.setByAddingObjectsFromSet(rhs)
}
 
x += y
assert(x == z)

Note that assignment operators defined in Swift don’t return the result of the assignment, to prevent errors like accidently typing if x = y instead of if x == y for Bool x, y. Our += operator follows that lead.

Examples

Being able to overload most of Swift’s operators is exciting; being able to define own operators even more so! On the other hand, an overloaded operator may be confusing; a new operator may be hard to type, and hard to understand. Let’s have a look at a couple of examples to better understand advantages and disadvantages.

Examples: Operator Overloading

Operators have certain traits we are used to. For example, from math we are used to addition working on values of the same type, being associative, meaning (a + b) + c is always a + (b + c), and being commutative, meaning a + b is always b + a.

In C, the + operator mostly keeps these traits. The only exception I am aware of is pointer arithmetic, where values of different types (a pointer and an integer) are added. Still, the operation stays commutative and associative.

int i = ...;
double *p = ...;
 
double *p1 = p + i;
double *p2 = i + p;
assert(p1 == p2);

Swift adds another exception: It defines a + operator for concatenating strings and arrays, which is not commutative:

println("Hello" + ", "+ "World")
println([1, 2] + [3, 4])

The Ruby programming language overloads the * operator, allowing to “multiply” an array with an integer, or a string. I think it’s only a matter of time before these appear in a third-party Swift module.

let rects = [CGRectZero]
let result1 = rects * 3
 
let tags = ["Swift", "Custom", "Operators"]
let result2 = tags * " "

Is that good or bad code? If you don’t know Ruby, try to guess what result1 and result2 are, then check below for the answer.

assert(result1 == [CGRectZero, CGRectZero, CGRectZero])
assert(result2 == "Swift Custom Operators")

A last example of overloading I’d like to show you is from the SwiftAutoLayout library. If you have ever created layout constraints in code, you may have noticed the code looks everything but pretty for simple constraints.

let constraint = NSLayoutConstraint(item: view1, attribute: .Height, relatedBy: .Equal, toItem: view2, attribute: .Height, multiplier: 1.0, constant: 0.0)

With the SwiftAutoLayout library, we can use operators to define constraints.

let constraint = view1.al_height == view2.al_height

It may be confusing at first that the “equal to” operator == returns an NSLayoutConstraint here instead of a Bool. As soon as we get used to that, the code using SwiftAutoLayout is much more readable.

Examples: Custom Operators

When we overload an existing operator, other programmers can guess the meaning of our operator from the original meaning. If we add a custom operator, we can borrow a meaning form another area like math, or logic.

That’s what we did when we added the logical operators. A much more complete version of that is Euler, a library published by Mattt Thompson of NSHipster fame.

We could also borrow a meaning for our custom operator from another programming language. Then at least users of that language would feel right at home. For example, there is a comparison operator <=> in Ruby which we could define in Swift as well. Another example is the swiftgo sample code, an incomplete implementation of goroutines in Swift that borrows Go’s <- operator.

If there is no operator to be found, we can still make one up trying to convey the meaning we want by choosing an adequate symbol. That’s what we did with the swap operator <->.

Recommendations

At the time of writing, Swift is still a young language, so take these recommendations with a grain of salt.

• We should never redefine predefined Swift behavior. Example: Don’t overload + on [Int] to make it an element-wise addition, as it clashes with the + on arrays which performs concatenation.
• When overloading an operator, try to keep its general idea, its “spirit” alive. Example: SwiftAutoLayout’s overload of == returns a constraint which specifies two attributes have to be equal to each other. Even though == does not return a Bool, I think it’s OK, because == still stands for a kind of equal to.
• If you overload an operator for which an assignment variant exists, overload the assignment variant as well if it makes sense. Example: Like shown with + and += for NSSet.
• If you think about adding an operator, think hard about the tradeoff brevity vs operator understanding. Example: Do ¬, ∧, and ∨ carry enough weight as alternatives to !, &&, and ||?
• If you add an operator, try to borrow a meaning from somewhere else. You can make up a new one as last resort, but then ask yourself why nobody else seemed to have the need for such an operator. Example: The swap operator <->.
• Most non-ASCII operators are hard to type. If you add non-ASCII operators in your project, make sure to add necessary text replacements via code snippets, or text expansion tools. We want to write code, not copy-paste it.

Simply put in an overused, albeit fitting pop-culture reference: With great power comes great responsibility. Don’t let the list of recommendations discourage you though. Swift is a new language, have fun and experiment!

You’ve reached the end of this article, I hope you learned something new — I certainly learned lots writing it down.

I have one last topic that may not be important enough for all readers, but still may be of interest to some. As before, I put in the last section as a bonus track. Feel free to skip that section, but be back for the next article of this series, which will be about structures!

Bonus Track: Boundaries of Operator Overloading

As Swift allows us to overload operators, I wondered how many of Swift’s operators can actually be overloaded by us: Afew? The majority? Almost all?

We can’t overload a couple of operators because we don’t have the syntax for it: The ternary conditional ? : (we can’t overload ternary operators), the cast operators is, as, and as? (we can’t use alphabetic characters in operators), the optional chaining operator ?, and the nil-coalescing operator ?? (we can’t use a question mark in operators).

In addition, we can’t overload three operators that are reserved by the compiler: the assignment =, the forced unwrapping postfix !, and the & prefix used for in-out parameters.

So we can’t overload 9 operators.

// ternary
? :
// infix
= is as as? ??
// prefix
&
// postfix
? !

But we can overload all remaining 46 operators:

// infix
+ += - -= * *= / /= % %= & &= ^ ^= | |= << <<= >> >>= &+ &- &* &/ &% || && < <= == != === !== >= > ..< ... ~=
// prefix
-- ~ ! + — ++
// postfix
-- ++

If we ignore the documentation and check Swift itself (1.0 in Xcode 6.0.1), we can overload two more operators: There is an undocumented infix operator ~> in the Swift library, and the compiler currently allows us to overload ?? as well.

In summary: Swift allows us to overload all but the most fundamental operators.

That’s all for today. Be back for the next article of this series, which will be about structures!

Facets of Swift, Part 5: Custom Operators was originally published in Swift Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Anatomy of a Function Declaration

A function declaration in Swift has the following format:

func functionName(parameters) -> returnType {
    // statements
}

To understand return types and parameters, it is helpful to know about tuples and tuple types in Swift. If you have read the second article of this series on tuples, great! You’re all set, and you can skip the next section. If you haven’t read the second article or you would like a refresher, just read on.

Refresher: Tuples and Tuple Types

Swift allows us to group two or more items in a tuple by putting the values in parentheses. We can access the elements of a tuple by their index:

var result = (200, "OK", true)
println(result.1) // Prints "OK"

We can optionally name some or all of the elements of the tuple. Named elements can be either accessed by index, or by their name:

var result = (code: 200, name: "OK", hasBody: true)
println(result.name) // Prints "OK"
println(result.1) // Prints "OK"

Tuple types are built by putting two or more types in parentheses, optionally giving them names. That beautifully mirrors how tuples are defined. When assigning tuples, the types of the elements must match. Furthermore, when names are given, the names must match:

var result: (code: Int, String)
result = (code: 200, “OK”)       // OK (no name mismatches)
result = (200, name: “OK”)       // OK (no name mismatches)
result = (200, “OK”)             // OK (no name mismatches)
result = (statusCode: 200, “OK”) // COMPILER ERROR (name mismatch)

There is also a tuple with no elements, the empty tuple with the empty tuple type.

var empty: () = ()

In the previous example, we declared the type explicitly as the compiler warns if the empty tuple type is inferred. The type Void is a type alias for the empty tuple type ():

var empty: Void = ()

For single values and types, parentheses are used to group expressions only: T, (T), ((T)), and so on all refer to the same type. In the following code snippet, foo has type Int:

let foo: ((Int)) = ((42))

Of course, the parentheses are not needed and the type can be inferred, so we can write shorter code instead:

let foo = 42

Return Types

After a short recap of what tuples are, we can compare the various possible return types in Swift. The return value of a function can be any single type, or any tuple type.

Returning Nothing

We can declare that a function returns nothing by using the empty tuple type:

func foo() -> () {
}

If we prefer, we can write Void instead of ():

func foo() -> Void {
}

The empty tuple type is the default return type for functions, so we can omit it to improve readability:

func foo() {
}

Having Void as default return type for a function is a better choice than in C, where the default return value is int:

foo() {
    return 42;
}

Why is that a better choice? Specifying nothing as a return type means that you get the closest thing to nothing there is in Swift, and not a number.

A Single Return Type

We can declare that a function has a single return type:

func foo() -> Int {
    return 42
}

I assume most of the Swift code we write will use either no return type, or a single return type. In C and Objective-C, we only have those two choices. The designers of Swift however decided to allow more.

Two or More Return Types

In Swift, we can use tuples to return more than one element from a function. We use the tuple type as return type, and return a tuple:

func okStatus() -> (code: Int, name: String, hasBody: Bool) {
    return (200, "OK", true)
}
let status = okStatus()
println(status.name) // Prints "OK"

To summarize: In Swift, a function’s return type is the empty tuple type by default. We can also use a single type, or a tuple type with two or more (optionally named) elements as return type.

Now that we know about return types, let’s have a look at parameters.

Parameters

Parameters offer even more possibilities than the return type. First, we’ll have a look at the parameter list itself. Then, we cover the three kinds of parameter passing, followed by explaining three special parameter kinds.

No Parameters

We can specify an empty parameter list by leaving the space between the parentheses empty. No surprises here:

func foo() {
}
foo(42) // COMPILER ERROR

That’s different in C, where empty parentheses are interpreted as an unspecified number of parameters:

void foo() {
}
foo(42) // NO COMPILER ERROR

Parameters for Objective-C blocks are handled in the same manner. The following code snippet compiles without errors:

void (^block)();
block = ^(int i) {
    printf("%d\n", i);
};
 
block();
block(1);
block([NSObject new], 42);

To state that we don’t want to allow parameters to be passed in C or Objective-C, we need to put void between the parentheses:

void foo(void) {
}
// ...
foo(42); // COMPILER ERROR

As with the return type, Swift has a better default behavior than C/Objective-C: Specifying no parameters means having no parameters, and not any number of parameters. But of course, functions that actually accept parameters are way more interesting.

One or More Parameters

To accept one or more parameters, just put the names and types between the parentheses of the function declaration, and the values between the parentheses of the function call:

func foo(x: Int, y: Int, z: Int) {
}
foo(1, 2, 3)

Now that looks very similar to what we’re used to from C.

Parameter Passing

As mentioned in the previous article, by default a parameter in Swift is passed as a constant. That means its value can’t be changed inside the body of a function:

func foo(i: Int) {
    i++ // COMPILER ERROR
}

If we want to, we can explicitly state that a parameter is a constant:

func foo(let i: Int) {
    i++ // COMPILER ERROR
}

By defining the parameter as a variable, we can change it inside the function body:

func foo(var i: Int) {
    i++
}

The changes won’t make it out of the function, though. If we would like to change the variable with which the function is called, we declare the parameter as an in-out parameter using the keyword inout. Then at the caller side, we have to pass in a variable which is prefixed with an ampersand:

func foo(inout i: Int) {
    i++
}
var x = 1
foo(&x)
println(x)

So we have three kinds of parameter passing. There are three kinds of special parameters as well.

Special Kinds of Parameters

The first special type is the ignored parameter. If we don’t want to use the value inside the function, but still require it as a parameter, we can use an underscore instead of a variable name:

func foo(_: Int) {
}
foo(42) // OK
foo() // COMPILER ERROR

An ignored parameter frees us of having to come up with a name for a parameter we don’t use, like when we override a method and don’t use a given parameter, or implement a closure and don’t use a given parameter. Both cases will be covered in detail in later articles.

For plain functions, I don’t see much use for an ignored parameter. That’s quite different for the second special kind of parameters: By using the type T…, we can make a function accept a variable number of values of type T. Inside the function, the parameter is exposed as an array with type [T]. The following code will print the numbers from 1 to 4, each on a separate line:

func printNumbers(numbers: Int...) {
    for number in numbers {
        println(number)
    }
}
printNumbers(1)
printNumbers()
printNumbers(2, 3, 4)

Such a parameter is called a variadic parameter. You may know variadic parameters from C and Objective-C, but maybe you never built a function with a variadic parameter because accessing the values was a bit of a pain. In Swift, a variadic parameter is very easy to use. I think we will see more of those.

The variadic parameter comes with a few strings attached. We may only use one per function. While that may seem as an unnecessary restriction, it prevents ambiguity and general code horror. The variadic parameter has to be the last in the list—a good design decision as it would feel really weird to have an optional number of parameters at the beginning, or in between other parameters. We can’t use inout on a variadic parameter: If we need to modify a list of values from our function, we can use an in-out array parameter instead. The documentation says nothing about using var on a variadic parameter, so we better avoid it. Besides, the current beta 5 compiler crashes if we try.

The third kind of special parameter is the parameter with default value. Imagine we write a helper function that prints a separator. This could be how the function looks like:

func printSeparator() {
    // ...
}

Two problems here. First, while the function name suggests that a separator is printed, there is no hint on how the separator looks. Second, we could not change the look of the separator. Default parameters to the rescue:

func printSeparator(separatorCharacter: String = "-", count: Int = 79) {
    // ...
}

Much better. Now the code suggests that the methods by default prints the “-” character 79 times. We also have the possibility to change those defaults:

printSeparator()                                    // (1)
printSeparator(separatorCharacter: "=")            // (2)
printSeparator(count: 50)                            // (3)
printSeparator(separatorCharacter: "=", count: 50) // (4)
printSeparator(count: 50, separatorCharacter: "=") // (5)

We would now expect that (1) prints “-” 79 times, (2) prints “=” 79 times, (3) prints “-” 50 times, both (4) and (5) print “=” 50 times. Things to note here are that we can skip default parameters from the beginning and only override later defaults (3), and that we are free to order the defaults however we want (4), (5). The most obvious difference is: Required function parameters in Swift are unnamed by default, parameters with default values are named by default. We have to pass the arguments by name, the following code would not compile:

printSeparator("=")     // COMPILER ERROR
printSeparator("=", 50) // COMPILER ERROR

The term “parameter with default value” is misleading. Both the Swift grammar, and the compiler allow a default expression:

func foo(number: UInt32 = arc4random()) {
    println(number)
}
foo() // Prints a random number

Parameter Order

We can put parameters with default values in front of parameters without default values:

func foo(a: Int = 0, b: Int) {
}
foo(2)
foo(a: 1, 2)

Try to avoid such code though, it’s hard to read. Better put required parameters first, followed by parameters with default values:

func foo(b: Int, a: Int = 0) {
}
foo(2)
foo(2, a: 1)

Parameter Names

We’ve seen that Swift has named and unnamed parameters. That’s not the whole story though. Each parameter in Swift has an external name and a local name. The external name is used when calling the function, the local name is used inside the function. In the following code snippet latitude is the external name, and lat the local name:

func foo(latitude lat: Float) {
    // ...
}
foo(latitude: 53.48)

If we don’t want to use an external name, we use an underscore instead; if we don’t want to use a local name, we use an underscore instead (which gives us an ignored parameter).

It would be quite annoying though if we would have to always write down external and local parameter. The Swift designers put defaults in place that help us to write shorter code. Whenever we miss an opportunity to write shorter code, the compiler warns us that our code is too long.

Naming Required Parameters

Coming from C, we are used to function parameters without external names. A plain function parameter in Swift does not have an external name by default as well. So instead of

func foo(_ lat: Float) {  // COMPILER WARNING
    // ...
} 
foo(53.48)

we can write

func foo(lat: Float) {
    // ...
}
foo(53.48)

If we like, we have the option to use an external name:

func foo(latitude lat: Float) {
    // ...
}
foo(latitude: 53.48)

If the external and internal name are the same, the compiler warns us that there is a shorter alternative:

func foo(lat lat: Float) {  // COMPILER WARNING
     // ...
}
foo(lat: 53.48)

The shorter alternative is to put a hash symbol in front of the parameter name:

func foo(#lat: Float) {
     // ...
}
foo(lat: 53.48)

Naming Parameters With Default Values

For a parameter with a default value, the default behavior is to use the same external and local name. So instead of

func foo(#lat: Float = 0.0) {  // COMPILER WARNING
    // ...
}
foo(lat: 53.48)

we can write

func foo(lat: Float = 0.0) {
    // ...
}
foo(lat: 53.48)

It is a good idea to name parameters with default values. If a function has more that one parameter with a default value, the names allow us to only change those parameters we want:

func foo(lat: Float = 0.0, lng: Float = 0.0) {
     // ...
}
foo(lat: 53.48)
foo(lng: 9.95)

We can still get an externally unnamed parameter with default value by using an underscore as external name:

func foo(_ lat: Float = 0.0) {
    println("Latitude: \(lat)")
}
foo(53.48)

Parameters with default values are a great way to keep compatibility when improving an existing API. We can add a new parameter with a default value.

// Before
func foo() {
    // ...
}
// After
func foo(x: Int = 0) {
    // ...
}

Old code still compiles without errors; new code can use the parameter to set another value than the default. Or we can add a default value to a preexisting parameter. Again, old code still compiles without errors, new code can call the function without the parameter.

// Before
func foo(x: Int) {
    // ...
}
// After
func foo(_ x: Int = 0.0) {
    // ...
}

Ignored Parameters

To ignore a parameter, we use the underscore as local name:

func foo(lat _: Float) {
}
foo(lat: 53.48)

If we don’t want to use an external name, we use an underscore as well:

func foo(_ _: Float) {  // COMPILER WARNING
}
foo(53.48)

The compiler warns us as there is a shorter alternative:

func foo(_: Float) {
}
foo(53.48)

Naming Parameters: Recommendation

When naming function parameters, we have lots of freedoms. Deviating from the defaults however can make our code harder to understand. Therefore we should try to use the default as much as possible.

Function Types

In C, we have function pointers which we can use to reference functions:

int sum(int a, int b) {
    return a + b;
}
// ...
int (*foo)(int, int) = sum;
printf("%d\n", foo(1, 2));

The variable foo has a function pointer type mapping two int parameters to an int return value. In Objective-C, we have block variables which we can use to reference blocks:

int (^foo)(int, int) = ^(int a, int b) {
    return a + b;
};
printf("%d\n", foo(1, 2));

The variable foo has a block pointer type mapping two int parameters to an int return value. In Swift, we have function types as well:

func sum(a: Int, b: Int) -> Int {
    return a + b
}
var foo: (Int, Int) -> Int = sum
println(foo(1, 2))

The variable foo has a function type mapping two Int parameters to an Int return value, or more exact mapping a tuple of type (Int, Int) to the type Int.

So Pretty

Swift’s function types are a huge improvement over C and Objective-C. It’s immediately obvious that they are way more readable. Imagine you want a variable foo with a function type that maps a function from Int to Int to a function from Int to Int. That’s both easy to write down in the first try, and easy to read:

var foo: (Int -> Int) -> (Int -> Int)

In C, the same variable would look like this:

int (*(*foo)(int (*)(int)))(int);

While some of us may write this down correctly in the first try, reading it is always painful. Granted, we could improve things a bit with a typedef, but even then the C code is less readable than the Swift version:

typedef int (*IntToInt)(int);
IntToInt (*foo)(IntToInt);

Swift’s function types also unify functions and closures (pieces of code without a name comparable to Objective-C blocks): Both have function types, so a variable with a function type can either reference a function or a closure. In contrast, Objective-C’s blocks are different to C’s function pointers. Closures will be covered in a later article.

Type Inference

If the type of the function can be inferred from the function, we don’t need to write the type of a function down:

func sum(a: Int, b: Int) -> Int {
    return a + b
}
var foo = sum
println(foo(1, 2))

The type can’t be inferred if the function is overloaded or uses generics. Then we have to write down the function type to specify which function we want. Here is an example where we get a lessThan function for Int parameters from the < operator:

let lessThan: (Int, Int) -> Bool = (<)
println(lessThan(1, 2)) // prints "true"

The parentheses around the < symbol are needed to make the compiler happy.

Function overloading, generics, and operators will be covered in later articles.

Void: Less Special Than in C

In C, there is no value for the type void, so you can’t declare a variable of void type:

void foo(void) {
}
// ...
void x = foo(); // COMPILER ERROR

Swift’s Void is less special than C’s void. It is a type alias for the empty tuple type (). So there is exactly one value for it, the empty tuple (). Because there is a value for the Void type, all functions in Swift have a return value! A function with return type Void simply returns the empty tuple:

func foo() {
}
var result: Void = foo()

The code even works without the type declaration on the variable result. The compiler only warns us we may not have intended to infer the empty tuple type:

func foo() {
}
var result = foo()  // COMPILER WARNING

We can even return the empty tuple from our function:

func foo() {
    return ()
}

An empty parameter list in Swift behaves just the same. A function foo() can be called with the empty tuple as parameter:

func foo() {
}
foo(())

What we should remember is: For Swift functions, Void is less special than in C: It is just a type with one valid value.

Function Types and Tuples

If you have read the bonus track of the second article of this series, you may remember that while Apple’s Swift book states that (Int) is Int, the other way round seems to be more accurate: All types behave like they are a 1-tuple. For example, the following code works just fine:

let x = 42
println(x.0)

We can also write down a named 1-tuple:

let x: (y: Int)  = 42
println(x.y)

That is wonderful because together with the handling of Void, it simplifies function types a lot. If we read a type T as 1-tuple (T) and ignore special parameter types, all functions in Swift map from an input tuple type to an output tuple type. No more special cases. Beautiful.

Of course, as Swift is a language still in beta, there are a couple of unexpected behaviors which are not that beautiful. As they may be confusing (and outdated pretty soon), I moved them to the last section as a bonus track. Feel free to skip that section, but be back for the next article of this series about methods!

Bonus Track: Parameter Misbehavior

There are two areas where the current (beta 5) Swift feels a bit weird: Handling of tuples as arguments, and special parameter types.

Tuples as Arguments

While a function’s parameters feel like a tuple type, the compiler sometimes needs to be convinced to accept a tuple. Here is some code I would expect to compile:

func foo(#a: Int) {}
 
let arg1 = (a: 42)
var arg2 = (a: 42)
 
foo((a: 42))    // COMPILER ERROR
foo(arg1)       // COMPILER ERROR
foo(arg2)       // COMPILER ERROR

We get compiler errors as Swift currently seems to not infer named 1-tuples. If we set a breakpoint, we see that arg1 and arg2 are of type Int, not (a: Int). Let’s try to help the compiler a bit:

func foo(#a: Int) {}
 
let arg1: (a: Int) = (a: 42)
var arg2: (a: Int) = (a: 42)
 
foo((a: 42) as (a: Int))
foo(arg1)
foo(arg2) // COMPILER ERROR

This compiles, except for the last line. Although the variable arg2 has the correct type, it is still not accepted by the compiler, while the constant arg1 is! To get the code to compile, we have to add yet another cast:

...
foo(arg2 as (a: Int))

In the future, Swift may change so that the casts are not needed anymore. The example illustrates an important point: Swift needs a named 1-tuple to represent the parameter type of a function with one named parameter. Here, the function type of foo is (a: Int) -> ().

The current compiler also gives us a bit of a hard time when using tuples with two or more elements as arguments. Here is an example I would expect to compile:

func foo1(a: Int, b: Int) {}
func foo2(a: (Int, Int)) {}
 
var arg1 = (42, 42)
var arg2 = 42
 
foo1(arg1)          // COMPILER ERROR
foo1(arg2, arg2)
foo1(42, 42)
foo1((42, 42))      // COMPILER ERROR
 
foo2(arg1)
foo2(arg2, arg2)    // COMPILER ERROR
foo2(42, 42)        // COMPILER ERROR
foo2((42, 42))

Why should all this work? Well, both foo1 and foo2 have the same function type (Int, Int) -> (). Again, we get a couple of errors. Again, we can fix the code by adding casts:

func foo1(a: Int, b: Int) {}
func foo2(a: (Int, Int)) {}
 
var arg1 = (42, 42)
var arg2 = 42
 
foo1(arg1 as (Int, Int))
foo1(arg2, arg2)
foo1(42, 42)
foo1((42, 42) as (Int, Int))
 
foo2(arg1)
foo2(arg2 as Int, arg2 as Int)
foo2(42 as Int, 42 as Int)
foo2((42, 42))

Let’s hope that gets cleaned up before Swift 1.0!

Tuples and Special Parameter Types

A function type maps from an input type (parameter type) to an output type (return type). There are three special types of parameters: in-out parameters, variadic parameters, and parameters with default values. The current Swift beta 5 compiler does not handle them that well.

If we define a function with an in-out parameter and check its type in the debugger, we see an attribute @lvalue on the inout parameter type. For the variable bar in the following code snippet, the debugger reports a type of (@lvalue Int, Int) -> ():

func foo(inout a: Int, b: Int) {}
var bar = foo

However, currently we can’t use @lvalue in our code to build a tuple we could use to call foo or bar with, nor is it a type we can write down. If we want to call the function with a tuple, we have to split the arguments manually:

func foo(inout a: Int, b: Int) {
}
 
var arg = (42, 42)
foo(&arg.0, arg.1)

For variadic parameters, the beta 5 debugger reports them wrongly as the empty tuple type. For the variable bar in the following code snippet, the debugger reports a type of () -> ():

func foo(a: Int...) {}
var bar = foo

That’s obviously wrong, as the function accepts any number of Int arguments.

Parameters with default values simply disappear in the reported function type, as if there were no defaults. For the variable bar in the following code snippet, the debugger reports a type of (Int, b: Int) -> ():

func foo(a: Int, b: Int = 42) {}
var bar = foo

Maybe this is by intention and bar should only be callable with both parameters? The compiler does not gives us a good hint: bar(1) is neither compiled successfully nor with an error, but it crashes the compiler. Maybe the next Swift version gives us a better hint what’s expected. Whatever happens to bar, there is no way to completely express the function type of foo, as there is no way of writing down a tuple type with defaults.

These rough edges should not discourage us, though. Swift’s function and function types are already way more impressive than what we have in C and Objective-C.

There are lots of interesting topics on functions still to cover, but this article already got way too long. I’ll write about those in future articles. Be back for the next article of this series, which will cover methods!

Facets of Swift, Part 4: Functions was originally published in Swift Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pass by Value

In C and Objective-C, values are passed everywhere, not references. What does the following code snippet do?

void foo(int i) {
    i++;
}
// ...
int x = 1;
foo(x);
printf("%d\n", x);

It will print “1”, as foo gets passed the value of x in the parameter i. So foo has no way of changing what’s stored in the variable x. When we try to convert the code directly to Swift, we stumble over a compiler error:

func foo(i: Int) {
    i++ // COMPILER ERROR
}
// ...
var x = 1
foo(x)
println(x)

In Swift, function parameters are constant by default. The function declaration above is shorthand for

func foo(let i: Int) {
    i++ // COMPILER ERROR
}

It’s a good thing that the default changed that way: In C, especially beginners could be fooled too easily into thinking that the first example would return “2”, not “1”.

If we want to modify the value of i in the function body in Swift, we can define i as a variable:

func foo(var i: Int) {
    i++
}
// ...
var x = 1
foo(x)
println(x)

Keep in mind that this still does not allow us to modify the value of the variable x that was passed in. Just as the C version, the code would now print “1”. What if we would like to change the value of the variable x?

Pass by Reference

In C, we would pass a pointer instead:

void foo(int *i) {
    (*i)++;
}
// ...
int x = 1;
foo(&x);
printf("%d\n", x);

Now foo gets passed the address &x (a reference to x), and can dereference that address using (*i) to change the value. The code will now print “2”. Keep in mind that from a technical perspective, this is still a pass by value: We pass the pointer as value.

In Swift, we use the keyword inout to tell the compiler that the variable is an in-out parameter:

func foo(inout i: Int) {
    i++
}
// ...
var x = 1
foo(&x)
println(x)

Compared to the C code, the Swift version looks a bit cleaner: While we still have to use & to pass a variable as an in-out parameter, we don’t need to dereference the parameter i to change the value. Inside the function, i feels like a variable, not a pointer.

In Swift, we use nothing or let to make a parameter constant, var to make it variable, and inout to make it an in-out parameter.

Constant Parameters in C

So the default in Swift is to have constant parameters. Can we have those in C as well? We can. But as it’s C, the story is a bit more complicated. Let’s start with this example:

void foo(CGSize s) {
    NSLog(@"%@", NSStringFromCGSize(s));
}
// ...
CGSize size = {1, 1};
foo(size);

It will print “{1, 1}”. Imagine CGSize would be a big structure, so we want to be able to pass it to foo via a pointer, but without worrying about foo changing it. We can achieve that by using const:

void foo(CGSize const *s) {
    NSLog(@"%@", NSStringFromCGSize(*s));
}
// ...
CGSize size = {1, 1};
foo(&size);

If we try to modify what s points to, we get a compiler error:

void foo(CGSize const *s) {
    (*s).width = 0 // COMPILER ERROR
}

The placement of const is crucial here. If we write const after the pointer, the code would compile:

void foo(CGSize *const s) {
    (*s).width = 0
}

To understand what’s going on, it helps to start reading from the variable name backwards. Still, covering all cases is quite a long list:

• CGSize s: s is a CGSize (which can be modified in the function). This is comparable to var s: CGSize in Swift.
• CGSize const s: s is a const CGSize, so it can’t be modified in the function. This is comparable to s: CGSize or let s: CGSize in Swift.
• CGSize *s: s is a pointer to a CGSize, so both the pointer s and the CGSize structure pointed to can be modified inside the function.
• CGSize *const s: s is a const pointer to a CGSize, so the pointer s can’t be modified inside the function, the CGSize structure pointed to can. This is roughly comparable to inout s: CGSize in Swift, as Swift hides the pointer from us, so we can’t modify it, but we can modify the value pointed to.
• CGSize const *s: s is a pointer to a const CGSize, so the pointer s can be modified, the CGSize structure pointed to can’t.
• CGSize const *const s: s is a const pointer to a const CGSize, so both the pointer s and the CGSize structure pointed to can’t be modified.

If you wondered about it, in all cases above we could replace CGSize const with its equivalent const CGSize.

We identified six cases, for three of which we don’t have a comparable construct in Swift. And that’s great:

• CGSize *s would force us to expose the pointer that Swift hides so well.
• CGSize const *s and CGSize const *const s can be used for performace optimizations in C: Instead of passing a copy of the struct’s value, we pass a pointer that does not allow the modification of the content. In Swift, we leave that optimization to the compiler, instead of polluting our code with it.

Now that we covered how constants work for structures and pointers, let’s have a look at what’s different for objects.

Objects

In Objective-C, we mostly work with objects which are subclasses of NSObject. Whenever we pass an object, or store it in a variable, we reference it using a pointer:

void foo(NSMutableString *s) {
}
// …
NSMutableString *string = [NSMutableString new];
foo(string);
NSLog(@”%@”, string);

An object variable should be able to hold an object of the respective class, or any subclass of it. Objects of different classes can have different sizes, so we can’t know the size. Therefore the compiler does not allow us to store the structure of an object in a variable directly, we have to use a pointer:

NSObject object1; // COMPILER ERROR
NSObject *object2; // OK

More importantly, we can’t use const to prevent changes to an object:

void foo(NSMutableString const *s) {
    [s appendString:@"OH NOES"]; // No compiler error here!
}
// ...
NSMutableString *string = [NSMutableString new];
foo(string);
NSLog(@"%@", string); // Prints "OH NOES"

We can make the pointer a constant, but as we’ve seen above for structures, that does not prevent us from changing the object pointed to, only from changing the pointer:

void foo(NSMutableString *const s) {
 [s appendString:@"OH NOES"];
}
// …
NSMutableString *string = [NSMutableString new];
foo(string);
NSLog(@"%@", string); // Prints "OH NOES"

In Swift, classes are reference types by default, so there is no need to write pointers:

func foo(s: NSMutableString) {
    s.appendString(“OH NOES”)
}
// ...
var string = NSMutableString()
foo(string)
println(string) // Prints "OH NOES"

Swift has the additional advantage that s is required to be non-nil (for details, see the first Facets of Swift article on optionals). The three cases for parameters in Swift cover all we need for objects:

• s: NSObject? is comparable to NSObject *const s in Objective-C. If we would like the parameter to be non-nil, we would use s: NSObject.
• var s: NSObject? is comparable to NSObject *s in Objective-C. If we would like the parameter to be non-nil, we would use var s: NSObject.
• inout s: NSObject? is comparable to NSObject **s, which is the short form of NSObject * __autoreleasing *s in Objective-C.

The last case shows how much cruft is removed in Swift. Bottom line: In Swift, objects are automatically passed by reference, which leads to better readable code, especially for inout parameters.

Gotcha: Focus on Values

When we look at Objective-C code, it almost always defines classes. For example, strings, arrays and dictionaries are objects of classes. That means that whenever we pass an object around in Objective-C, we use a pointer which needs memory management by ARC. There are only a few exceptions where values are used instead of objects, most notable primitive types like BOOL and NSInteger, and simple structures like CGPoint, CGSize and CGRect.

Swift has a focus on values. While it is still possible to define classes, the basic types of Swift are structures or enumerations that are passed around by value. The compiler may use references for performance, but that’s not our job anymore.

While values are easier to understand and to use than references, coming from Objective-C we are used to reference types. It may be confusing to see the semantics change. To illustrate the problem, let’s have a look at an example where we store a mapping from string to an array of strings. Here is the Objective-C code:

@interface StringLists : NSObject
 
- (void)addString:(NSString *)string forKey:(NSString *)key;
- (NSArray *)listForKey:(NSString *)key;
 
@end
 
@implementation StringLists {
    NSMutableDictionary *_stringLists;
}
 
- (instancetype)init {
    self = [super init];
    if (self) {
        _stringLists = [NSMutableDictionary new];
    }
    return self;
}
 
- (void)addString:(NSString *)string forKey:(NSString *)key {
    NSMutableArray *list = _stringLists[key];
    if (list == nil) {
        list = [NSMutableArray new];
        _stringLists[key] = list;
    }
    [list addObject:[string copy]];
}
 
- (NSArray *)listForKey:(NSString *)key {
    return [_stringLists[key] copy];
}
 
@end

Notice the two copy calls. The first one prevents users of the class to accidently pass us an NSMutableString that they mutate afterwards. The second one is not strictly necessary, but a precaution against someone casting and changing the mutable array afterwards.

If we translate the Objective-C code one-to-one to Swift, a first try may look like this:

class StringLists {
    var stringLists: [String: [String]] = [:]
 
    func addString(string: String, forKey key: String) {
        var list = stringLists[key]
        if !list {
            list = []
            stringLists[key] = list
        }
        list!.append(string) // COMPILER ERROR
    }
 
    func listForKey(key: String) -> [String]? {
        return stringLists[key]
    }
}

In Swift, arrays, dictionaries and strings are structures with value-semantics. That means we don’t need to copy anymore. But that also means that coming from Objective-C, things may not behave as we would expect. The first gotcha is the compiler error. That’s because the forced value expression list! returns a value that we cannot mutate, comparable to C and Objective-C where we can’t mutate a value returned from a function directly. Here is some Objective-C code we would not expect to work:

[array count]++; // COMPILER ERROR
[view frame].size = CGSizeZero; // COMPILER ERROR

While the Swift compiler may change in the future to allow mutation of list!, for now we have to store it in a variable first:

func addString(string: String, forKey key: String) {
    var list = stringLists[key]
    if !list {
    list = []
       stringLists[key] = list
    }
    var unwrappedList = list!
    unwrappedList.append(string)
}

But that would not work as well. A comparable error in Objective-C would be to try to set the size of a view’s frame to CGSizeZero like this:

CGRect frame = [view frame];
frame.size = CGSizeZero;

What’s of course missing is that we need to write the changed value back:

CGRect frame = [view frame];
frame.size = CGSizeZero;
[view setFrame:frame];

As arrays in Swift have value semantics, we need to write the changed value back as well:

func addString(string: String, forKey key: String) {
    var list = stringLists[key]
    if !list {
        list = []
        stringLists[key] = list
    }
    var unwrappedList = list!
    unwrappedList.append(string)
    stringLists[key] = unwrappedList
}

Now the code works, but it looks a bit messy. That’s because we translated from Objective-C one-to-one. Let’s clean it up:

func addString(string: String, forKey key: String) {
    if var list = stringLists[key] {
        list.append(string)
        stringLists[key] = list
    } else {
        stringLists[key] = [string]
    }
}

What we should remember: In Swift, arrays, dictionaries, and strings have value semantics.

While I was writing this article (before Xcode 6 beta 3), the array in Swift behaved in a way that most developers found strange. Now have sane value semantics for the array.

Still, I could not resist writing a bit about the old array semantics, and for which scenarios it made sense. That’s not relevant for today’s understanding of Swift though, so feel free to skip the last section below, and continue reading the next article of this series on functions!

Bonus Track: Swift’s Old Array

Before the third beta of Swift, the Array type had a behavior that most developers found weird. If we had a constant array defined with let, we could still change the values in the array, but we could not change its size. So this actually worked before:

let x = [2006, 90, 74, 54]
x.sort(<)
x[3] = 2014
println(x) // Printed [54, 74, 90, 2014]

What we could not do is change the size of the “constant” array, that is, we could not append a value, for example.

This behavior could actually be explained quite easily: An Array in Swift was like a struct with a pointer to the internal storage. With that in mind, everything made sense: a “change” would mean a change to the pointer, and that was only needed if the length of the array changed.

So why would anyone embrace such a weird behavior? My guess is not only performance, but that it simplified implementing functions that worked on arrays. If we used a range subscript on an array, we got back a slice that still allowed changing the original array:

let x = [54, 74, 90, 2006]
let last = x[3..4]
last[0] = 2014
println(x) // Printed [54, 74, 90, 2014]

Because of that, we could use slices as views on the original array, which simplified implementing algorithms like quicksort. Normally, recursive implementations start out like this:

// CAREFUL: This was valid Swift before beta 3,
// it does not work anymore
 
func quicksort(v: Int[]) {
    quicksort(v, 0, v.count — 1)
}
 
func quicksort(v: Int[], left: Int, right: Int) {
    if left >= right { return }
    
    let pivotIndex = partition(v, left, right)
    quicksort(v, left, pivotIndex - 1)
    quicksort(v, pivotIndex + 1, right)
}

Both quicksort and partition have three input parameters. With the old Swift array behavior, we could use slices instead:

// CAREFUL: This was valid Swift before beta 3,
// it does not work anymore
 
func quicksort(v: Int[]) {
    quicksort(v[0..v.count])
}
 
func quicksort(v: Slice<Int>) {
    if v.count <= 1 { return }
   
    let pivotIndex = partition(v)
    quicksort(v[0..pivotIndex])
    quicksort(v[(pivotIndex + 1)..v.count])
}

Suddenly the code is more readable, because the slice parameter abstracted away the left and right offset: Instead of left, we could use 0, instead of right + 1, we could use the count of the slice. That simplifies writing the partition function, because we don’t have to make a lot of index calculations.

Still, we should be very happy about the change, because now a constant array is immutable, as it should be.

I hope you enjoyed the article, and learned a thing or two you didn’t know. The next article of this series is about functions in Swift. See you there!

Facets of Swift, Part 3: Values and References was originally published in Swift Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

This second article is about Swift’s tuples. Tuples allow us to write more compact code. In addition to that, tuples are a prerequisite to understanding functions, methods and closures, which will be the topic of later articles.

What is a Tuple?

We may remember the concept of tuples from math or computer science. There, a tuple is simply an ordered list of values, where the type of each value is fixed. In Swift, it’s about the same. To build an n-tuple, we just put the values in parentheses:

var result = (200, "OK", true)

Here result is a 3-tuple that holds three values: 200 (an Int), “OK” (a String) and true (a Bool). The variable result has a tuple type. To declare a tuple type, we use parentheses as well:

var result: (Int, String, Bool)
result = (200, "OK", true)

Accessing Tuple Elements

The most common method of accessing a tuple’s elements is by decomposing the tuple:

var result = (200, "OK", true)
let (statusCode, statusMessage, hasBody) = result

Now the three constants statusCode, statusMessage, and hasBody have the values 200, “OK”, and true. If we are not interested in a value, we can use an underscore instead of an identifier, the so-called wildcard expression:

var result = (200, "OK", true)
let (statusCode, _, _) = result

We can also access the elements of a tuple by their index:

var result = (200, "OK", true)
let statusCode = result.0

If a tuple is variable, we can initialize the tuple by setting the elements:

var result: (Int, String, Bool)
result.0 = 200
result.1 = “OK”
result.2 = true

Naming Tuple Elements

Of course, the last example is not self-documenting: It’s hard to understand what it is about as the elements of the tuple are not named. Well, we can do that:

var result: (statusCode: Int, statusText: String, hasBody: Bool)
result.statusCode = 200
result.statusText = “OK”
result.hasBody = true

To define the variable result in a shorter way, we can also use type inference:

var result = (statusCode: 200, statusText: "OK", hasBody: true)

We don’t have to name all elements of the tuple. You can think of the element names as add-on parts of the tuple type. Provided that tuple length and types match, the assignment will work as long as there are no name conflicts:

var result = (statusCode: 200, statusText: "OK", true)
var result2 = (statusCode: 404, "Not Found", hasBody: true)

result = result2                             // OK
result2 = result                             // OK
result = (code: 200, statusText: "OK", true) // ERROR

Later on we’ll see why this is a good choice. What we’ve seen so far: Tuples in Swift can be used to group, and optionally name, related values.

Before we dive into the various usage scenarios of tuples in Swift, let’s have a look at two special cases: The tuple with no elements and the tuple with only one element.

Not that Special: The 0-Tuple

As a tuple is a list of elements, can we define an empty tuple, that is a tuple with no elements? Yes we can:

var empty: ()
empty = ()

The code above defines the variable empty to hold the so-called empty tuple type, and afterwards assigns the empty tuple to it. The empty tuple in Swift is not special, it’s just a tuple with no elements.

There is a typealias in Swift for the empty tuple type called Void:

var empty: Void
empty = ()

Note that you can’t use Void as value: It is a type, not a value. So this won’t compile:

var empty: Void    // OK
empty = Void       // COMPILER ERROR

The only difference of the empty tuple to a tuple with two or more elements is that the compiler currently gives us a warning if the empty tuple type is inferred from the empty tuple: If you compile this:

var empty = ()

the compiler will give you a warning: “Variable ‘empty’ inferred to have type ‘()’, which may be unexpected”.

Now that we know about the 0-tuple, what about the 1-tuple?

Special: The 1-Tuple

In contrast to the empty tuple or tuples with two elements or more, the 1-tuple is really special. Because there is no 1-tuple in Swift. If we declare

var a: Int
var b: (Int)
var c: ((((((((((Int))))))))))
var d = 42
var e = (42)
var f = ((((((((((42))))))))))

all the variables a to f all have the same type: Int. At first, this may feel like a horrible inconsistency. But it’s not.

First, depending on your background, it may not feel like an inconsistency. In some parts of math and computer science, an n-tuple type is a product of n types: T = T1 x … x Tn. A 1-tuple would consequently be the type itself: T = T1. So with that background, it feels right that there is no 1-tuple.

Second, if parentheses around a single element would return a tuple type, we could not use parentheses to group anything. Here are a two examples:

var mapping: (Int -> Int)?

The variable mapping is an optional function from Int to Int. If parentheses around a single element would return a tuple type, we would not be able to define the type of the variable mapping.

var n = 5
var sumOfNumbersToN = (n * (n + 1)) / 2

sumOfNumbersToN is inferred to the type Int. That’s how it should be. If parentheses around a single element would return a tuple type, we would get in trouble as multiplication and division would have to be defined on tuple types as well, and sumOfNumbersOfN would maybe end up to be a tuple type.

To summarize: There is no 1-tuple in Swift, only the value itself. There is no 1-tuple type in Swift, only the type itself.*

(* but read the bonus track at the end of this article on how the beta 4 compiler disagrees with that)

Now let’s have a look where tuples are used in Swift.

When to Use Tuples

As tuples form a group of elements, they are used in all places where such a group is useful. The first and simplest use for tuples is multiple assignment. Instead of

var x = 1
var y = 2
var z = 3

we can write

var (x, y, z) = (1, 2, 3)

The second use is to return multiple values from a function. Imagine in our app we often need both the result of the division and the remainder for integers a and b:

let quotient = a / b
let remainder = a % b
println(quotient, remainder)

So we define a function that returns both in a tuple:

func divmod(a: Int, b: Int) -> (quotient: Int, remainder: Int) {
    return (a / b, a % b)
}

(Sidenote: I am aware that this should rather be an extension on Int, or a custom operator, but those are topics for future articles.)

Now we can decompose the result of the function:

let (quotient, remainder) = divmod(a, b)
println(quotient, remainder)

Alternatively, we can store the tuple result of the call, and access the individual elements:

let result = divmod(a, b)
println(result.quotient, result.remainder)

The above example illustrates why Swift’s designers chose to make assignment work from non-named tuple elements to named tuple elements and vice versa: If we would be forced to match the names, neither the return statement of the function, nor the decomposition of the function’s result would work.

The third use of tuples is when iterating an array or dictionary. Inside the for…in statement, we use tuple decomposition:

for (key, value) in dict {
    // ...
}
for (index, value) in enumerate(array) {
    // ...
}

Instead of the decomposition, we could get the tuples as well:

for keyValueTuple in dict {
 // ...
}
for indexValueTuple in enumerate(array) {
 // ...
}

The fourth use of tuples is in switch statements. Swift’s switch statements are very powerful. They can also match tuples. Here is an example showing the power of the matching:

var point = (x: 5, y: 5)
switch point {
case (0, 0):                        // (1)
    println("Origin")
case (_, 0):                        // (2)
    println("On x-axis")
case (0, _):                        // (2)
    println("On y-axis")
case let (x, y) where x == y:       // (3)
    println("On 1. diagonal")
case let (x, y) where x == -y:      // (3)
    println("On 2. diagonal")
case (-1...1, -1...1):              // (4)
    println("Near origin")
default:                            // (5)
    ()    
}

The above example shows matching a tuple with concrete values for the elements (1), using the wildcard operator (2), using binding and a where statement (3), as well as using ranges (4).

If you wonder about the parentheses after default (5), that’s the empty tuple. In Swift it is not allowed to have a case or default in a switch statement without a following expression, and the empty tuple () is a short, valid expression. You can also use 0 if you prefer.

As we know from C and other languages, default matches everything that’s not handled in the cases above. If Swift would not have a default keyword, we could use case (_, _) or case _ instead.

When Not to Use Tuples

At the time of writing, Swift is only a couple of weeks old, so take the following recommendations with a grain of salt.

Tuples allow us to group related values easily, but we should not use them to replace better suited data structures. There are some indications when you may prefer a data structure to a tuple type:

• The strongest indication is that you have a good name for the group of elements of a tuple. Then choose a struct or class with that name.
• If you would like to define functions that take the tuple as a parameter, try to come up with a name for a struct or class, and define the function as a method on that type.
• If the tuple contains elements which are optional and mutually exclusive: An enum is a better way to express that.

That’s it for this article. I tried to only show what’s documented about Swift’s tuples. However, there are some things I stumbled upon when writing the fourth part of this series, which I summarized in the following section. Beware: It is not needed to do Swift programming, it’s purely based on pushing the boundaries of a new language that’s still in flux. It may be confusing. So you may skip the last section and continue reading the next article of this series, where we will have a look at values and references in Swift.

Bonus Track: Tuples All the Way Down

Still here? Great! Let’s have a look at a variable declaration:

var foo: (Int) = 42

The Swift Programming Language iBook tells us if we use (Int) it is simply Int, not (Int). Also, it tells us that as a result, we can only name tuple elements if there are at least two elements.

Well, let’s see whether the compiler disagrees with the documentation:

var foo: (x: Int) = 42
println(foo.x)
println(foo.0)

It does: This works fine and prints 42 two times. So yes, we can name tuple elements if there is only one element in the tuple, and yes, there seems to be a named 1-tuple in Swift. In the fourth article of this series, we’ll see an explanation why the existence of a named 1-tuple makes sense.

Let’s check again whether there is a 1-tuple:

var foo: (Int) = 42
println(foo.0)

Wait, what? That works fine as well. The documentation says (Int) is simply Int. Maybe it’s the other way round? Maybe Int is (Int)? Maybe everything is a tuple?

var foo: Int = 42
println(foo.0)

Works fine as well. But that’s not all. If Int is (Int) then shouldn’t it by induction also be ((Int))? Or even ((((((((((Int))))))))))?

var foo: Int = 42
println(foo.0.0)
println(foo.0.0.0.0.0.0.0.0.0.0)

It is. In Swift, there are tuples all the way down. At least in beta 4.

In the next article of this series, we will have a look at values and references in Swift.

Facets of Swift, Part 2: Tuples was originally published in Swift Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

What are Optionals?

In Objective-C, there is no explicit optional value. To illustrate where that can pose problems, let’s have a look at a method that returns the index of an item in a todo list:

- (NSInteger)indexOfItem:(Item *)item {
    // ...
}

Here, the item is implicitly optional: We can either pass an instance of Item, or nil. On the other hand, the return value is implicitly non-optional: As NSInteger is not an object type, there is no way not to return a value.

For the item parameter, it would make sense to require a non-nil value. But that’s not possible in Objective-C. For the return value, it would make sense to be able to return nil if the item is not in the list. But that’s not possible in Objective-C. We can only add documentation what happens if a nil is passed as an item (error or not?), and which value is returned in case the item is not in the list (NSNotFound which is defined as NSIntegerMax? Or NSIntegerMin? Or -1?).

Wouldn’t it be great if we had to explicitly write down which values are optional? Well, that’s the case in Swift. A type T is non-optional. To allow the absence of a value, we use the optional type T?. We may define the method like this:

func indexOfItem(item: Item) -> Int? {
    // ...
}

Here the method declaration requires that we pass an item. Trying to pass nil would result in a compile-time error. Also, the method explicitly expresses that the return value is optional, so we don’t need to define a special Int value to model the absence of the index.

A variable v of type T? has a couple of differences to a variable of non-optional type T:

1. It can not only hold values of type T, but also the empty value nil.
2. It is initialized to nil.
3. To access the value of type T which may be stored in v, we have to unwrap the value first.

Unwrapping Optionals

Let’s say we would like to write a method that returns the one-based index of the item in a list (let’s call it the natural index, because it is more natural to start counting from 1). In Objective-C, the implementation may look like this:

- (NSInteger)naturalIndexOfItem:(Item *)item {
    NSInteger indexOrNotFound = [self indexOfItem:item];
    if (indexOrNotFound != NSNotFound) {
        return indexOrNotFound + 1;
    } else {
        return NSNotFound;
    }
}

If we write the respective code in Swift, a first attempt may look like this:

func naturalIndexOfItem(item: Item) -> Int? {
    let indexOrNotFound = indexOfItem(item)
    if indexOrNotFound != nil {
        let index = indexOrNotFound!
        return index + 1
    } else {
        return nil
    }
}

The ! behind indexNotFound unwraps the optional value to a non-optional. So index has the type Int, and the compiler does not complain about the addition.

If indexOrNotFound would be nil, then unwrapping would fail with a runtime error. The expression indexNotFound! is for that reason called a forced-value expression.

Optional Binding

Of course, the first attempt is not the best solution: The code is now longer than in Objective-C. We can do much better. First, as we often need to unwrap a value and then use it, Swift provides something called optional binding:

func naturalIndexOfItem(item: Item) -> Int? {
    let indexOrNotFound = indexOfItem(item)
    if let index = indexOrNotFound {
        return index + 1
    } else {
        return nil
    }
}

If we use let or var in the condition of an if statement, the constant/variable is set to the unwrapped value, so we don’t need to unwrap anymore. We can now inline indexOrNotFound:

func naturalIndexOfItem(item: Item) -> Int? {
    if let index = indexOfItem(item) {
        return index + 1
    } else {
        return nil
    }
}

Instead of adding 1, we can call successor() on index:

func naturalIndexOfItem(item: Item) -> Int? {
    if let index = indexOfItem(item) {
        return index.successor()
    } else {
        return nil
    }
}

But even that is way too much code in Swift. Enter optional chaining.

Optional Chaining

The essence of the method above is calling the successor function on indexOfItem(item). The rest is just the handling of the optional value. However, we can’t write

func naturalIndexOfItem(item: Item) -> Int? {
    return indexOfItem(item).successor()
}

That will lead to a compiler error, as the method successor is not defined on the optional type returned by indexOfItem(item). And it should not compile, as we ignored the optional case. What about unwrapping with the forced value expression?

func naturalIndexOfItem(item: Item) -> Int? {
    return indexOfItem(item)!.successor()
}

Now as soon as the item is not in the list, we would get a runtime error. What works is optional chaining which is done with ?:

func naturalIndexOfItem(item: Item) -> Int? {
    return indexOfItem(item)?.successor()
}

If an object a is of optional type, a?.b returns nil if a is nil, otherwise it returns b. In Objective-C we have implicit optional chaining on objects: If we have a variable item that holds an item or nil, which can belong to a list or not, and a list can have a name or not, we get the name of the list or nil by calling

NSString *listName = item.list.name;

In Swift, for the same case we would need to write:

var listName = item?.list?.name

Is that preferable? Yes, it is. We have to explicitly state how we handle optional values. Even better, we can narrow down which parts are really optional and which aren’t. We can get rid ot the first question mark by making item a non-optional variable. We can get rid of the second question mark by making the list property non-optional. Finally, we can make the variable listName a String instead of a String? by making the name property non-optional.

Bottom line: In Objective-C, we can’t make objects non-optional and we can’t make other types optional. In Swift, we can.

Implicitly Unwrapped Optionals

There is a second optional type in Swift: The implicitly unwrapped optional. It is needed for various reasons, one of them is better compatibility with Objective-C libraries. A good example is the method +currentDevice on UIDevice. In Objective-C, it looks like this:

+ (UIDevice *)currentDevice;

How could the signature of such a method be bridged to Swift? First try:

class func currentDevice() -> UIDevice

That won’t work. While we are pretty sure that currentDevice will always return a value, that is not true for all Objective-C methods and properties. For example, both the method anyObject on NSSet and the property superview on UIView may be nil.

We could use an optional:

class func currentDevice() -> UIDevice?

That would work fine. The disadvantage is that our code would be cluttered with lots of unwrapping, optional chaining and so on, even though most of the methods in UIKit return non-nil objects. Imagine we would like to have the name of the current device as an NSString. Even though we know that both the device and its name are not nil, we would have to write:

var name = UIDevice.currentDevice()!.name!

Not pretty. What we would like to have is something that can still be nil, but that we do not have to unwrap ourselves. That’s the implicitly unwrapped optional, which is marked with an exclamation mark:

class func currentDevice() -> UIDevice!

A variable v of type T! has one difference to a variable of optional type T?: It will be implicitly unwrapped to type T. Because of that, we don’t need to unwrap anything here:

var name = UIDevice.currentDevice().name

name will now inferred to be of type NSString!, but that’s not a problem since it will be automatically unwrapped when it is accessed.

So whenever we have an Objective-C method or property that we know will not return nil, we can use it just like a non-optional. If we know that the value may be nil, we can use optional binding and chaining to prevent runtime errors.

The implicitly unwrapped optional has not been added for Objective-C support alone, though. In Swift it helps us with chicken-egg problems where an object needs a reference to another object which is not available at initialization time. The simplest example I could come up with is a recursive closure. Let’s say we would like to define factorial, and print out factorial(12). First try:

var factorial: Int -> Int
factorial = { x in (x == 0) ? 1 : x * factorial(x — 1) }
println(factorial(12))

The compiler will rightly complain that we can’t use factorial inside the closure, because at that point, the variable is not initialized. We could work around by making factorial an optional:

var factorial: (Int -> Int)?
factorial = { x in (x == 0) ? 1 : x * factorial!(x — 1) }
println(factorial!(12))

Now our code is cluttered with unwrapping even though it is glaringly obvious that factorial will be defined when accessed. An implicitly unwrapped optional is the best solution:

var factorial: (Int -> Int)!
factorial = { x in (x == 0) ? 1 : x * factorial(x — 1) }
println(factorial(12))

In Swift, we have non-optionals, optionals and implicitly unwrapped optionals.

Optionals of Bool values are quite interesting, as these give us three choices. Let’s have a look on how to cover these three choices in code.

Optional Bool

If we use an optional boolean type (Bool?), it can be unwrapped to true or false, or be nil. There are a couple of ways to cover all three cases. We can unwarp the optional variable:

var authenticated: Bool? = false
if let authenticated = authenticated {
    if authenticated {
        println("Authenticated")
    } else {
        println("Not authenticated")
    }
} else {
    println("Unknown")
}

If we don’t like the structure of the code, we can cover the three cases on the same level:

var authenticated: Bool? = false
if authenticated == true {
    println(“Authenticated”)
} else if authenticated == false {
    println(“Not authenticated”)
} else {
    println(“Unknown”)
}

We need the comparisons above as authenticated is an optional, and since Swift beta 5, we can’t use optionals directly as logic values, however, we can use them directly in comparisons with ==. Besides, the respective Objective-C code using NSNumber *authenticated would definitely look worse.

If we prefer to, we can also use a switch statement.

var authenticated: Bool? = false
switch authenticated {
case .Some(true):
    println(“Authenticated”)
case .Some(false):
    println(“Not authenticated”)
default:
    println(“Unknown”)
}

I don’t like it that much though for a couple of reasons. First, we have to use .Some which is part of the implementation of optionals (it’s done with an enum type, but that’s a story for another article). Second, even if we cover all three possible cases in the switch statement, the compiler will complain we have not exhausted all cases. That’s because of the current internals of Bool. Don’t ask. So we have to use a default instead of the third case.

What about other gotchas with Swift’s optionals?

Gotchas

Having optionals is something we don’t have in Objective-C, so a couple of things may be confusing at first. The biggest gotcha is that question mark and exclamation mark as postfix on a type T are quite different to their counterparts used on an expression v:

• T? is the optional type
• T! is the implicitly unwrapped optional type
• v? is used for optional chaining
• v! is used for unwrapping

Things that may be confusing here:

• If we have a non-optional type T, we can use ? and ! on it. If we have an expression v of non-optional type T, we can’t use ? and ! on it, as both chaining and unwrapping don’t make sense on a non-optional.
• We can use ! on both expressions of type T! and T?
• We can use ? on both expressions of type T? and T!

The last bit of confusion is the behavior of the ? postfix on an expression v if we use it without calling anything on it. Then it just returns v as an optional. So if v is either of type Int? or of type Int!, and we declare

var v2 = v?
var v3 = v???????????

, both v2 and v3 will be of type Int?.

Recommendations for using Optionals

At this point, Swift is only a couple of weeks old. So take the following recommendations with a grain of salt.

First, don’t use the optional chaining operator ? on its own, but always with a following dot. Its name already points to its main use: optional chaining.

Second, while technically possible, don’t use optionals of optionals. Yes, you can define something like var v: Int?!!. But don’t. Please don’t.

Third, try to avoid the implicitly unwrapped optional, except when you’re really sure that it will be always filled. A lot of the Cocoa APIs are still not annotated correctly and return T!, but from a programmer’s perspective, most should either return T?, or T.

Last but not least, only use optionals where you need them, and where the extra case actually makes sense. For example, if you model a todo list that has a name and items, the items property can always be a non-optional Array. The name property can be a non-optional String. Only make the name optional if you really need to distinguish between a sensible default like the empty String and the case that the name is unset. Swift’s optionals and implicitly unwrapped optionals are great. But non-optionals are the default for a reason.

In the next article of this series, we’ll have a look at Swift’s tuples.

Facets of Swift, Part 1: Optionals was originally published in Swift Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.