<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=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 2, 2016, at 2:02 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><blockquote type="cite" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">On Nov 2, 2016, at 3:47 PM, Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">For what it’s worth, I concur. I think type narrowing makes it feel more like the language is actually doing some work *for* me rather than me having to babysit the language with some new syntax or keyword.<br class=""></blockquote><br 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;" class=""><span 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; float: none; display: inline !important;" class="">I’ve been staying out of the discussion because it doesn’t seem particularly relevant to Swift 4 phase 1, but +1. Type narrowing is by far the most general and scalable solution which could be applied in other ways in the future.</span><br 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;" class=""><br 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;" class=""></div></blockquote><div><br class=""></div><div>Same as me, I was staying out as well. </div><div>+1 for type narrowing instead of the original proposal. Thank you Haravikk for bringing this up.</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><blockquote type="cite" class="">On Nov 2, 2016, at 3:25 PM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">I still think that type narrowing is the right way to handle this like so:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>if x != nil {<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-tab-span" style="white-space: pre;">        </span>// x is definitely not nil inside this block (implicitly unwrapped)<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>} // x remains optional outside of it<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>if (x != nil) || (x == y) {<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-tab-span" style="white-space: pre;">        </span>// if y's type is non-optional, then x is definitely not nil inside this block also<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-tab-span" style="white-space: pre;">        </span>// i.e- if all conditions narrow to the same result, the type is narrowed inside the block<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>}<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>if x is Foo {<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-tab-span" style="white-space: pre;">        </span>x.someMethodSpecificToFoo()<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>}<br class=""><br class="">Personally I'm very much against the use of shadowing in the first place, and never use it myself. I tend to precede unwrapped value with "this" like so:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>if let thisFoo = foo {<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-tab-span" style="white-space: pre;">        </span>// Do something with thisFoo<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>}<br class=""><br class="">I know it's maybe down to personal preference but I'd prefer to discourage shadowing entirely, and focus on type-narrowing, as it's a much more natural, and more generally useful, way to handle this "problem", as it doesn't actually require a specific syntax at all; if your condition narrows the type, then you can use the variable as whatever it is known to be.</blockquote></blockquote></div></blockquote></div></div></body></html>