Update 12 Oct ’16: I’ve updated the code in this post and the Xcode Playground blog post version to Swift 3! Thank you for the wait 😁

As an iOS developer, handling empty value cases in Objective-C is never easy. Let’s suppose we’re making a function that return NSString instance out of a NSDictionary:

Everything seems fine, isn’t it? The method’s logic is pretty clear – it returns the value in user_token key of the JSON. If the key exists, it will return the string. If not, it will return a nil value… dead simple, right?

No.

I left out a sanity check there, but  let’s continue our example for now.

Suppose that the returned string will be encrypted and stored by C++ library. And for that, we need to cast our NSString to C string:

Where’s the problem, Do? Everything looks fine…

Right. The method above looks good – it stopped the process early if passed userToken is nil. Both of them will work correctly, until somebody from the server side single-handedly pass null value in response JSON’s user_token key, instead of omitting it.

Let’s run through the code once again. If the passed JSON is made from NSJSONSerialization process, the user_token key will store a NSNull  instance. Thus, the result from userTokenFromJSON: will be a NSNull instead of a nil or NSString – which will allow it to pass through storeUserToken:‘s early sanity check code (since it’s not a nil), and break the whole app, since NSNull doesn’t have UTF8String method.

Let’s hope this case will never happen in production servers. And yes – I’m looking at you, cowboys.

Due to this issue, nil-checking alone in Objective-C isn’t sufficient. We also need to ensure whether an instance is the right class using isKindOfClass: method. It doesn’t always work well either – for example, if the server on the example above returns a number for user_token value, there’s a chance that it’ll read as _NSCFString (Apple’s private API) instead of a NSNumber.

That’s why after a few month working with Swift,  I grew appreciating the Swift Team’s decision to include Optionals. I believe they made this as an answer to Objective-C’s tedious sanity check. The documentation clearly says that:

You use optionals in situations where a value may be absent. An optional says:

• There is a value, and it equals x

or

• There isn’t a value at all.

If I declare a variable to be a String? (read: String Optional), it would either be a String value or a nil. Not a NSNull, not other class type, and not another Apple’s private API. So, userTokenFromJSON: above could be rewritten in Swift into this:

And yes, this method will an Optional – either  String or a nil. 🙂 But the process isn’t ended here – we need to take the available String value out of the Optional. The term is usually called as unwrapping in Swift development – and there are several ways to do it!

Wait, it seems I had enough rant above… this post started to feel edgy. Let’s change the mood, shall we?

In this post, I’ll list the ways for unwrapping Swift’s Optionals that I have found so far. For the sake of the post, let’s assume we got a new function that needs a String input and an Optional variable:

Now, we need to unwrap the name (since it’s a String optional) to pass it to the createGreetings(sailorName:). There are several ways to do this:

1. Force unwrap (!)

Ah, the ol’ forceful way. Adding bang / exclamation (!) mark after the variable is a sure way to keep the compiler from whining:

Sure, the whining stops – but at what cost? Force-unwrapping a nil-valued Optional will raise an exception, which will happen on the second createGreetings call of the code above.

Of course, we could do some nil checking before force unwrapping. Still, it will make our code twice as forceful as the code above:

Thankfully, Swift provide a better way to do this.

2. if let

An if let statement is just like the nil-checking statement above, but less bangs 😉 we pass the non-nil value to a new variable, and execute the code inside the if let statement:

Since it only passes non-nil values, it won’t execute the code inside the statement if the variable is a nil. The code in if let statement below won’t be executed:

And, since naming things is the second hardest thing in Computer Science, we could reuse the variable name for the if let statement. The compiler will use the unwrapped version for the code inside it:

So, we knew that if let is more beneficial than force unwrap. While it’s convenient, we could end up big or nested if let statement for complicated logic:

Assume the if let bracket above got several dozen lines of code – it would be cumbersome, no? It would be even worse if there’s another if bracket inside it. Of course, we could use return early method, but we’ll be forced to force-unwrap:

Thankfully, Swift 2.0 provides a solution that allows us to return early cleanly:

3. guard let

Swift’s guard syntax forces a code block to return early when its condition is not met. It also works with let for unwrapping optionals:

Neat, right? With guard, we could handle the outlier cases on the top of the code block, and proceed with the normal case below it. Still, there are times that we only need if let or guard let only to return a value, such as below:

For this specific use case, Swift provides a simple shortcut:

4. nil-coalescing operator (??)

Based on the documentation, nil-coalescing operator (??) unwraps an optional if it isn’t a nil, and returns the other value otherwise. Simply put, it’s a shortcut of a != nil ? a! : b.

This allows us to implement the code above with less code:

Besides the common operators above, there’s another way to unwrap optionals – which is based by the implentation of the optionals itself.

5. switch

Why switch statement, you ask? Long story short, I found Benedict Terhecte’s blog post about advanced enum usage a few months ago. There’s a simplified implementation of Swift’s optional there, that turned out to be an (somewhat like) enum with associated values:

Knowing this, we could use switch‘s pattern matching to unwrap its values:

This is beneficial if we got two optionals and different conditions according to their values (or absence of it). On my latest project, I created a view model to cater date selection in a calendar. This is the super simplified version:

Though we could implement the update(selectedDate:) method above using “equal-nil” checking, but IMO, it’s more self-describing with switch‘s pattern matching.

Bonus: flatMap for Arrays

There’s a flatMap built-in method for Swift Array that can be used to filter-out nil values. Here’s an example:

It will only work if we return Optional element on the flatMap block, though. Here’s a sample to test it:

CMIIW, but from what I know, flatMap is meant to take a nested value inside an array and put it to the surface level (hence the flatten), and map it as needed. At first, I only think this will be useful to flatten a nested array:

The duckSailors and sealSailors above were Strings that nested inside a container – which is an array. Returning the exact array in otherSailors‘ flatMap block will flatten out the values inside it.

If we revisit the simplified Optional implementation above, we could see that it’s just another container – that may contain something (.Some(T)), or none (.None). That’s why the flatMap operation filters out nils – because those Optional contains nothing! 😉

I hope you find this post useful! See you later on future posts! 😄

P.S: I’ll try to post an updated version of this for Swift 3 soon! 😉