Optional of an Optional

Optional of an Optional

During a recent debugging session, I came across an Optional of an Optional of an entity. 😱 Well, I've read about this in theory but experiencing it in practice is definitely interesting. Intro first.

Optional Basics

Optional is a (generic) type that is used to represent the presence or absence of a value. Here's its declaration:

public enum Optional<Wrapped>: ExpressibleByNilLiteral {
  /// The absence of a value.
  case none

  /// The presence of a value, stored as `Wrapped`.
  case some(Wrapped)


I've left out some method definitions in the type such as map, flatMap etc along with a couple of its extensions.

@frozen is a Swift attribute that guarantees no further cases will be added (removed or reordered) on the enum declaration (This facilitates some compiler optimizations and allows a user to perform an exhaustive matching on the cases with no need for a default/'unknown' case check. For more info, check out this and this Swift Evolution proposal). Wrapped is the generic type to be wrapped by the Optional. ExpressibleByNilLiteral conformance denotes that this type that can be initialized using the nil literal, nil.

Before continuing with our discussion, it's important to mention that the Optional type gets some extra compiler love:

  • A trailing question mark (?) on a type is treated as an Optional wrapping that type. This eases reading and writing Optionals in code. For instance, the following two declarations are the same.

--> let optionalString: Optional<String> = nil

--> let optionalString: String? = nil

  • If let, while let, guard statements can evaluate the Optional and control program flow based on the presence or absence of the wrapped value.
  • Sending a message to an Optional that represents an absence of a value results in a no-op e.g. optionalString?.removeAll() does nothing if optionalString is nil.
  • Checking for equality with an Optional type (where Wrapped conforms to Equatable) promotes the non-optional value to an optional to make the types e.g. nonOptionalString == optionalString works out of the box.

These and many other nifty 'tricks' make working with Optional beautiful in Swift.

Optional of an Optional

Being a generic, Optional can thus be over any type including another Optional something like Optional<Optional<String>> aka String??.

Take an example of the following declaration. What's the type of languages?

let languages = ["Swift", "Kotlin", nil, "Rust"]

A quick glance would yield an assumption of Array<Any> but on closer inspection, we note that it's intuitive for the compiler to infer Array<Optional<String>> aka Array<String?> of which it does.

What's the type of first here let first = languages.first?

Now you've got it. It's a Optional<Optional<String>>.

Here's my attempt to explain. An element of the languages array is an Optional wrapping a string. The first property of an array (declared as public var first: Element? { get }) yields an Optional wrapping the Element -- the single type held by the array. In our case, it's an Optional wrapping a String and hence we get Optional<Optional<String>> 🤯!

Therefore, in the snippet below, you need to be aware that print is working with an Optional<String> (from reasons mentioned so far).

guard let first = languages.first else { return }


In many cases, the compiler will emit warnings and offer fixes such as: Screen Shot 2020-09-10 at 6.52.32 hwa-inī.png

or subtle ones like the following (NB: self.deserializeEntity(from:) returns a T?): Screen Shot 2020-09-10 at 6.54.54 hwa-inī.png


And there you have it. Optionals make representing absence of a thing intuitive in Swift and have many uses such as in collections to denote a sentinel value when retrieving an element or during iteration. Being a generic, Optionals can be over any type including a couple of optionals such as String????? -- which is the valid, rather unuseful, type: Optional<Optional<Optional<Optional<Optional<String>>>>>.

Anyways. You get the idea. 🙈

let signOut: String? = "Happy Coding!"



Did you find this article valuable?

Support Charles Muchene by becoming a sponsor. Any amount is appreciated!