<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><font face="Monaco" class="">if x != nil {</font></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// x is definitely not nil inside this block (implicitly unwrapped)</font></div></div></blockquote></div><br class=""><div class="">Pyry already mentioned the problem that arise when x is a variable (is "x = nil" forbidden inside the block?).</div><div class="">Properties add complications as well (especially, but not only, computed ones), and everything beyond simple checks for nil would be a potential source of big confusion:</div><div class=""><span style="font-family: Monaco;" class="">if (x == y) {</span></div><div class="">What if one of the values can change? Forbidding that would be odd, but if you don't oppose strict limits, there is no way to guarantee that the initial conditions are still valid throughout the block.</div><div class=""><br class=""></div><div class="">In general, I think Swifts approach is very good, because it saves us from the "magic" that has to be involved when the compiler infers traits based on checks done in the source.</div></body></html>