Keep your option(al)s open

I'm a Swift Newbie. And its humbling to say the least. But I'm definitely seeing parallels with other object oriented programming languages such as Java. One prime example is the Optional type. optionals were recently introduced to  the Java development ecosystem (JDK8) But as any Java developer would know, third party libraries such as Guava supported the optional type way before Java 8 was a thing. Guava, anyone? No, not the fruit. Check this out for more on Guava optionals specifics. The resource also highlights some common regrets with nulls in general. In a nutshell, they suck! (thanks Doug Lea for the quote!)

In short, optionals give us the option (see what I just did there) to store an existing value of a specific type or nothing at all. For example, let's say we want a variable to hold someone's middle name. Not everyone has a middle name so we want to allow the possibility of a missing value. So I want a variable called middleName to hold a person's middle name. Since my middle name is "Kaur", I would set middleName to "Kaur" and the optional would be associated with an actual value. However my fictitious friend may not have a middle name. So I need my variable to account for both scenarios - present and not present.

In Java, I can define the above scenario as follows

Optional<String> middleName;middleName = Optional.of("Sonya");

System.out.println(middleName.get()); // prints out the result: "Sonya"

In Swift, I would declare the following

var middleName: String?

middleName = "Kaur"

middleName!

So what's the exclamation needed for in the third line from the Swift code snippet listed above? Well, if you use an Optional, you just can't use the optional type on its own. To get to the actual content, you need to unwrap the optional and obtain the value. Its kind of like unwrapping a gift. You remove the gift wrap to see the gift! In Swift, you can force unwrap an optional using an"exclamation point." Note the word force - this force unwrapping comes with a caveat. Forcibly unwrapping an optional makes an assumption that it holds a non-nil value and all will be well. When you forcibly unwrap an optional, you're taking a risk and telling the compiler - "Hey compiler, I know what I'm doing and this optional definitely has some meat to it." So the compiler lets you do your thing.  However, if the “value” is indeed nil (missing), an unexpected error will occur and all will not be well. In Swift/iOS jargon, the error will result in a trap and the application will sadly terminate.  Oops. 

fatal error: unexpectedly found nil while unwrapping an Optional value

This is not good. There has be a better way of getting a handle to the actual content of the optional.

Enter "optional binding." A clean and safe way to unwrap an optional using the if-let construct. Remember let in Swift is used to declare constants, values that cannot be changed once declared. The if-let allows you to assign the optional to a temporary constant of the non-optional type. If the optional is not nil, the assignment allows you to proceed forward and use the non optional value in code. If its nil, you can handle that scenario in your code gracefully in the else conditional block. Its almost like using the conditional if-else but with more magic! Below are two quick examples I wrote using the Xcode Playground. The first is when the optional holds a nil and the second when it holds a valid middleName. No more "trap"doors!🚪 😎

A. Since middleName is nil, the else condition will be invoked

B. middleName exists and is set to the constant