He was right. I went back on the Swift book
, 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
value means something slighltly different.
Let's have a look.
You define an
as impliticly unwrapped when you define its type like this:
let x: String!
This technique allows you to tell the compiler to automatically unwrap that value, as if it wasn't optional at all.
which is a syntactic sugar for
is equivalent to
A common example of implicitly unwrapped optionals is how view controller define their
@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
value, to automatically unwrap it, without having to check whether it is
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
example and inthe previous post, unwrapping an
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
s. I'd rather sprinkle
s all around my code then access a
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
values? Get in touch on Twitter @mokagio
or leave a comment below.
Thanks again Daniel for pointing my mistake out, leading to me learning more about Swift, an writing this post :smile:.
Leave the codebase better than you found it