[swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Daniel Hooper]

A very common pattern in swift code is to "guard let" or "if let" optionals
 - this works by creating a new non-optional variable to be used by future
code. Often, the new variable is given the same name as the original
optional variable, creating a shadow variable. This approach leads to odd
looking code like this:

if let nearestX = nearestX { closest = nearestX }
guard let layer = layer else { continue }
// use layer

At a glance, and to Swift newcomers, this code looks completely
non-sensical. It's also verbose for simply ensuring the variable is
non-nil.

The solution:
Swift should generate unwrapped shadow variables after nil checking. The
compiler would treat the below code as if it had created an unwrapped
shadow variable.

if nearestX != nil { closest = nearestX } // notice that nearestX isn't
force unwrapped
guard layer != nil else { continue }
// use layer, without force unwrapping

Why force unwrapping isn't a good alternative:
You might suggest force unwrapping variables when they're inside an if or
after a guard that checks for nil. While this does allow for the "layer =
nil" syntax, it results in code that is less resilient to change. Imagine
that this code was written:

{code:java}
if layer != nil {
// lots of code before //
layer!.backgroundColor = newColor
// lots of code after //
}
{code}

And much later, you need to use some of the the code in the if body
elsewhere, so you copy and paste a huge chunk of it. You likely won't
notice the force unwrap, and unless you're lucky, you probably didn't paste
it into an if that checked layer for nil. So you get a crash. Because of
this, it's important we make safe optional unwrapping as easy and sensical
as possible, and minimize the situations that you would need to force
unwrap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/f25a1757/attachment.html>