This post is a followup to a "Why Implicitly Unwrapping Swift Optionals Is Dangerous". Daniel H Steinberg , on Twitter as @dimsumthinking, pointed out to me that the terminology used in the poost wasn't accurate:
@mokagio Actually your article is about explicitly unwrapped optionals not implicitly unwrapped. Very different.— dimsumthinking (@dimsumthinking) July 27, 2016
He was right. I went back on the Swift
did more reading, and understood that what I kept referring to as implicitly
unwrapping is a technique actually
called force unwrapping, and that to implicitly unwrap an
means something slighltly different.
Let's have a look.
You define an
Optional as impliticly unwrapped when you define its type like
let x: String!
This technique allows you to tell the compiler to automatically unwrap that value, as if it wasn't optional at all.
Type? which is a syntactic sugar for
A common example of implicitly unwrapped optionals is how view controller
@IBOutlet var messageLabel: UILabel! @IBOutlet var actionButton: UIButton!
It makes sense to define the outlets as implicitly unwrapped optionals because their are going to be instantiated by Interface Builder. It would be cumbersome to always unwrap each view outlet inside view controllers.
Because of their implicitly unwrapped nature, if you forget to connect an outlet to it Interface Builder view an run the app you'll get a runtime error when you try to access it in the view controller.
Force unwrap, or force-unwrap, or forced unwrapping, is the technique most
of the previous post was actually about. It consist in adding a
Optional value, to automatically unwrap it, without having to check
whether it is
nil or not.
let strings = ["mokacoding", "is", "a", "blog"] let firstLength: Int = strings.first!.length
Like implicitly unwrapping, force unwrap uses a
! and makes the compiler
treat an otherwise optional value as the type it wraps. Unlike implicitly
unwrapping though, this technique is used on existing values.
You define a type as implicitly unwrapped,
and you force unwrap a value which has
They are both dangerous
@dimsumthinking While semantically different, the end result of using either of the two tools is the same though: less runtime confidence— You can call me Joe (@mokagio) July 28, 2016
As said in the
IBOutlet example and in the previous
Optional value without taking into account its nullability is
dangerous, it can in fact crash your app.
There are some scenarios in which implictly or forced unwrapping an
can make sense, such as the outlets scenario. It is up to us as developers to
take into account the tradeoff between code that is easier to consume, versus
code that leverages the compiler to guarantee its safety.
My take on this? Never use
! apart for
IBOutlets. I'd rather sprinkle
guard letss all around my code then access a
nil value and crash
my apps because something changed an the assumption "its never going to be
which I made when I wrote that
! is no longer valid, but I forgot about having
written it in the first place.
How do you feel about impliticly unwrapping or force unwrap
Get in touch on Twitter @mokagio or leave a
Thanks again Daniel for pointing my mistake out, leading to me learning more about Swift, an writing this post 😄.
Leave the codebase better than you found it