<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’ve had similar ideas to this. Instead of ditching the <font face="Menlo" class="">if let</font> syntax altogether, another approach would be to use the existing name if no new name is given, so that this code:<div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let foo = foo { /* use foo */ }</font></div><div class=""><br class=""></div><div class="">could become this code:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let foo { /* use foo */ }</font></div><div class=""><br class=""></div><div class="">In both cases, <font face="Menlo" class="">foo</font> is non-optional inside the braces. If you gave it another name with the <font face="Menlo" class="">if let</font> syntax, that would work as it does today.<br class=""><div class=""><br class=""></div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><div class="">Jeff Kelley</div><div class=""><br class=""></div><div class=""><a href="mailto:SlaunchaMan@gmail.com" class="">SlaunchaMan@gmail.com</a> | <a href="https://twitter.com/SlaunchaMan" class="">@SlaunchaMan</a> | <a href="http://jeffkelley.org" class="">jeffkelley.org</a></div></div></span></div></div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Dec 11, 2015, at 11:11 AM, Daniel Hooper via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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:</div><div class=""><br class=""></div><div class="">if let nearestX = nearestX { closest = nearestX }<br class=""></div><div class="">guard let layer = layer else { continue } </div><div class="">// use layer</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">The solution:</div><div class="">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.</div><div class=""><br class=""></div><div class=""><span class=""><div class="">if nearestX != nil { closest = nearestX } // notice that nearestX isn't force unwrapped<br class=""></div><div class="">guard layer != nil else { continue } </div><div class="">// use layer, without force unwrapping</div></span></div><div class=""><br class=""></div><div class="">Why force unwrapping isn't a good alternative: </div><div class="">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:</div><div class=""><br class=""></div><div class="">{code:java}</div><div class="">if layer != nil {</div><div class="">// lots of code before //</div><div class="">layer!.backgroundColor = newColor</div><div class="">// lots of code after //</div><div class="">}</div><div class="">{code}</div><div class=""><br class=""></div><div class="">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.</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=oWipMi1-2F8XMs8QRRfapD5Mv-2FGx-2FUhuBfYnkgklXk1OEowkvcvokU9-2BQ-2FinepiHdcAYDoRu-2B2bKxhoJcA53JwRaK-2FH0ZWPNf1osQqJzbUYy-2F4ZJEXS9qRKLIhCP7XqwLmVf52wSBGeejQ91JneYj6teGXKFoTyhxPsn5E68AdPD4LGXT4UuiGSyX5rBrKJvZWC-2FsSrG-2Ff1Bc80eq-2BEkHZ2KUKKEYOPebovbowpX35e2k-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>