Swift loves it’s optionals (or nullables if you come from a C# background).

Whilst optionals may lead to fewer unhandled null reference exceptions or the likes they also lead to different ways of unwrapping values.

Declaring variables

First off let’s look at declaring a string type, we might write

let s: String = "Hello"

This is not an optional declaration and hence requires an initial value, i.e. remove the = “Hello” and the compiler complains or try to set to nil and the compiler complains – because this variables is expected to be non-nil. If we want to declare a type as possibly being nil then we need to mark it as such using the optional syntax.

Declaring optionals

let s: String? = "Hello"

The ? on a variable/value declares a type of optional string. We can also declare options in a long hand form

let s: String = Optional.some("Hello")

Equally, the following are equivalent

let s1: String?
let s2: String? = Optional.none

Basically we’re saying a “some” value or “none” value or nil may be assigned to this variable.

One thing to note regarding optionals is that to get the actual value assigned, you have to “unwrap” it from the optional. Basically think in terms of your variable is wrapped in an Optional type and to access it, you need to get (unwrap) the value out of that type.

Implicitly unwrapped optional

Interestingly Swift also has implicitly unwrapped optionals. Whereas an optional may have a value, no value or nil, an implicitly unwrapped optional may only contain a value or nil. Here’s the syntax for implicit optionals (note the trailing !)

let s: String!

The general use of an implicitly unwrapped optional is where maybe you declare a value initially but know it will be set to a value before use and will not be nil again.

Obviously we can still check if a value is nil or not, but the compiler will assume you know what you’re doing so if you’re using a value that’s nil the compiler will not warn you.

Note: If you come from a language like C# or Java, then in the example above, just think that this is more like the way you’d declare Strings in those languages and ofcourse you have the same issues regarding ensuring the value is non-nil/null in those languages.

Why not just using implicitly unwrapped optionals as they seem simple? The main reason is the same as why C# introduced nullable reference types. If you want to do things yourself, no problem, but if you want the compiler to highlight potential misused of variables, i.e. have the compiler warn if it looks like you might be using a nil. Then you’re best to only use implicitly unwrapped optionals sparingly and stick to the optional equivalent.

If you’re a little confused by implicitly unwrapped and optionals, let’s look at this code

var s1: String?
var s2: String!

print(s1.length)
print(s2.length)

Neither variable has been set to a value, hence both are none or nil. If we compile this code the Swift compiler will complain with

error: value of optional type ‘String?’ must be unwrapped to refer to member ‘length’ of wrapped base type ‘String’
print(s1.length)

Because the compiler has our back.

Now commenting out print(s1.length) and recompiling, all looks good to the compiler, but ofcourse when we run this code it’ll blow up with an error such as

Unexpectedly found nil while implicitly unwrapping an Optional value

Basically the compiler see’s the implicitly unwrapped optional essentially ignore it as we (the developer) told it that we know what we’re doing.

Unwrapping an optional as part of a conditional test

We’ll often wish to check if an optional is nil or not and then unwrap it to get the actual underlying value. Using the following syntax does both steps in one go

if let optionalValue = optionalValue {
   // do something with the unwrapped optionalValue
}

Swift also supports the guard statement which is basically another condition operator so we can also unwrap in the same way as above, but with a guard, i.e.

guard let optionalValue = optionalValue else {
   // failed to unwrap
   return
}

// do something with the unwrapped optionalValue

Switch

We can use a switch statement on optionals as well, for example

let s: String? = "Hello"
switch s {
   case .some(let s): print("SOME \(s)")
   case .none: print ("NONE")
}

Using map with optionals

We can use map with optionals

let x: String? = "Hello"
let y = x.map { $0 + "World" }
// y is a String?

Unwrapping with !

In some situations you may know an optional value is not nil in which case you simply wish to unwrap the value without any conditional code in place, that’s when you used the ! operator to force unwrap – basically the developer is saying this is a valid value so just unwrap it. Ofcourse, if the developer is wrong then this will have unintended consequences.

The syntax is as follows

let optionalValue: String? = "Hello"

print(optionalValue!)

Optional chaining

We can use the optional chaining ?. operator on types, for example

let optionalValue: String? = "Hello"
print(s?.count)

The nil coalescing operator

Along with the optional chaining operator ?. we also have the nil coalescing operator

let optionalValue: String? = "Hello"
print(optionalValue ?? "NONE")

I’d been wondering why, when creating some types in Swift I was seeing a requirement to unwrap the type. After all, surely if I created a types it’s not nil and hence why does it need to be optional?

Well Swift does actually allow us to declare a type’s init as optional, for example

struct Email {
   var address: String

   init?(address: String) {
      // not really much of a validation step
      // but in the real world we could ensure
      // the address matches an email regex
      guard address.count > 0 else {
         return nil
     }
   }
}

This is pretty useful as it means if we initialize a type with invalid values, we can simple return a nil optional object instead of the alternative of throwing an exception or the need for a two phase initialization.

The URLSession.shared.dataTask completionHandler passes us three pieces of information. Data, the response from an HTTP request and an error.

Transport errors are returned within the error object but HTTP status codes which we’d possible class as errors are supplied in the response object, so I wanted both transport and HTTP status errors to be returned as an Error.

Note: I’m not using URLSession.shared.data as it’s not currently supported on Linux, from what I can tell.

The code below creates a new dataTask method that is async and returns a Result<Data?, Error>. Let’s first look at new dataTask method without the status code handling

private func dataTask(with request: URLRequest) async -> Result<Data?, Error> {
   await withCheckedContinuation { continuation in
      URLSession.shared.dataTask(with: request) { data, response, error in
         if let error = error {
            continuation.resume(returning: .failure(error))
            return
         }
         continuation.resume(returning: .success(data))
    }.resume()
}

So this creates a continuation which is used as a promise/future/task by calling the continuation resume method with either a success or failure.

As already mentioned, this will not return 404’s (for example) as errors. So let’s simply add code to create a failure when certain HTTP status codes appear. We might want to differentiate between the two types of error, i.e. transport layer and HTTP, so first off let’s create our Error subclass, which looks like this

public enum HTTPError: Error {
    case transportError(Error)
    case httpError(Int)
}

This will allow us to pass back the Error from the URLSession.shared.dataTask completion handler for transport errors and the code from the HTTP status for HTTP errors.

Now we’ll change the earlier code to look like this

private func dataTask(with request: URLRequest) async -> Result<Data?, Error> {
   await withCheckedContinuation { continuation in
      URLSession.shared.dataTask(with: request) { data, response, error in
         if let error = error {
            continuation.resume(returning: .failure(HTTPError.transportError(error)))
            return
         }

         let resp = response as! HTTPURLResponse
         let status = resp.statusCode
         guard (200...299).contains(status) else {
            continuation.resume(returning: .failure(HTTPError.httpError(status)))
            return
         }

         continuation.resume(returning: .success(data))
    }.resume()
}

Now we can check the Result<Data?, Error> for the error and see what type of error it is, for the example below I actually throw the error for the caller to catch

let result = await dataTask(url: url!, httpMethod: "POST", httpBody: httpBody)
if case .failure(let error) = result  {
   throw error            
}