Getting the optional value inside an array - ios

Question

Given an optional array of type Book, declared in a table view controller class:
var books: [Book]?
Later in cellForRowAtIndexPath I have:
let cell = tableView.dequeueReusableCell(withIdentifier: "cellID", for: indexPath)
let book = books?[indexPath.row]
cell.textLabel?.text = book?.title
return cell
}
Now, so far I have only seen this books array optional unwrapped using if let statement in order to loop through the array.
But why in cellForRow here do we not unwrap books and unwrap book instead of adding another ? after it, as in books?[indexPath.row] and cell.textLabel?.text = book?.title

Answer 1

You don't have to unwrap books or book because the text property of the UILabel is an optional String?. The only time you have to unwrap optionals is if you're using the retrieved value in some context that doesn't accept an optional. But text does, so your example operates fine.
My problem with this syntax is that, while it's a useful shorthand, this is a bit sloppy. If there is a programming problem (for example, books is nil when this is called even though that technically shouldn't be possible), the code in the question will silently continue executing and you will be left scratching your head, wondering why the label in the cell was blank. (This is also true for patterns that suggest using guard statements, quietly returning the cell if the unwrapping failed.)
But I strongly disagree with suggestions provided elsewhere that books should not be an optional. If this array cannot be populated at the time the view controller is instantiated, then books should be an optional (and be nil) until such time that this information is retrieved.
Bottom line, there is a difference between state of "books has not yet been set" and "books was populated, but no records were returned". This is the purpose of optionals, to avoid arbitrary sentinel values like "empty array" to indicate that books does not have its value set. (I am sympathetic to those who object to the sloppy overuse of optionals, but this simply is not one of those cases. And I'm not buying the Optional performance overhead concern, either, because it is immaterial in this example and it strikes me as a perfect example of premature optimization.)
I believe, instead, that you should (a) leave books optional; but (b) detect if it is unexpectedly nil and report this as the error it is, because if cellForRowAt is called, it must not be nil.
Thus, I would suggest:
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "BookCell", for: indexPath)
let book = books![indexPath.row]
cell.textLabel?.text = book.title
return cell
}
This accomplishes what we want, populating the label correctly, but will also immediately take the developer to the offending line of code if there was a code logic error and books was nil.
Now, many developers have a maniacal aversion to using the ! forced unwrapping operator. Personally I think it's fine because it's a fundamental programming error if books was nil when this method was called, and the forced unwrapping operator will stop my execution at the offending line and I'll know precisely what the issue is.
But, if you really want to avoid the forced unwrapping operator, !, then use a guard statement, triggering an informative fatalError if books is nil:
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "BookCell", for: indexPath)
guard let book = books?[indexPath.row] else {
fatalError("No book found")
}
cell.textLabel?.text = book?.title
return cell
}
The key is that if a situation arose where books was nil, you want to know immediately in the development process, not left guessing what the source of the problem was.
To be clear, this forced unwrapping and/or fatalError pattern should never be used in situations where the unwrapping could ever fail for reasons outside of your control. For example, don't use these patterns when parsing responses from remote web service or processing user input. You want to gracefully handle errors that might have resulted outside of your control. But if it is a true program error for a particular scenario to take place, then forced unwrapping and/or fatalError approaches are advisable so logic errors are immediately apparent, rather than forcing you to hunt around looking for the source of aberrant app behavior.

Answer 2

An optional unwrap using ? means that if the value exists, unwrap it. This is ok to do (safe to do) if you don't plan on using the potentially nil value elsewhere. In your case, you could technically do it this way (it will compile, and likely won't crash), but it's not the safest way, because now you're relying on each piece along the way to support a nil value.
That said, you don't really need to declare your array as optional. Because you're enumerating the number of rows of data anyway, the array should always exist. The variable is the number of rows it contains, not whether it exists or not. In other words: checking that the array exists on top of checking the number of rows is just extra work for the compiler and extra code for you to write.
You can also take advantage of guard too, reducing the amount of code that executes if you don't have good data:
// ...
guard let book = books[indexPath.row] else { return cell }
cell.textLabel?.text = book.title
return cell

Answer 3

Never declare a data source array of a non-optional table view or collection view as optional.
var books = [Book]()
That makes your life so much easier
let cell = tableView.dequeueReusableCell(withIdentifier: "cellID", for: indexPath)
let book = books[indexPath.row]
cell.textLabel?.text = book.title
return cell
}