<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 7, 2016, at 8:03 PM, Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 7 Nov 2016, at 16:29, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>> wrote:<br class="">I'm simply worried a little about unwanted effects and additional compiler "cleverness".<br class=""></blockquote><br class="">I don't believe there should be any; either the type is narrowed or it isn't, if you rely on it being a type the type-checker can't verify, you'll get an error, otherwise you won't. There shouldn't be scope for anything unexpected.</div></div></blockquote><div><br class=""></div><div>True. </div><div><br class=""></div><div>I'm simply worried about the compiler speed in general, that's what I meant by "cleverness". The implicit variable typing and other features of Swift already IMHO make it incredibly slow and various features analyzing the code in order to determine the correct type can slow it even further. For comparison, a 100KLOC project of mine in pure Swift takes about 8 minutes to compile, vs. 3 minutes when it was in ObjC. With no optimizations turned on.</div><div><br class=""></div><div>But I agree that designing a language around the compiler speed is wrong, but I believe designing the language without taking it into account is just as wrong. It's not worth designing features that would make the compilation so slow it would render the language unusable.</div><div><br class=""></div><div>Note that I have only very limited experience with compiler implementation, I've only made a few minor things with Clang a few years back, so please feel free to correct me.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">Xcode's migration is "nice", but I'd like to point out that migration to Swift 3 of my project took 6 hours (!) and I spent almost 2 more days manually changing what the migrator didn't manage to do on its own. And that was one of my projects. I really don't want to go through this once more.<br class=""></blockquote><br class="">I agree, but the only code that should be affected by this is code where there is unwrapping that can be determined to either be redundant, or is definitely incorrect; in the former case it will only be a warning (so you can remove force unwrapping that is no longer needed) and in the latter it will be an error because the type-checker has actually identified something that will definitely cause a run-time error.</div></div></blockquote></div><div class=""><br class=""></div><div class="">There are two cases:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">if foo != nil { </font></div><div class=""><font face="Menlo" class=""> foo!.doSomething() </font></div><div class=""><font face="Menlo" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">Currently, accessing a non-optional value with ! produces an error:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">let foo = Bar()</font></div><div class=""><font face="Menlo" class="">foo!.doSomething() // ERROR</font></div></blockquote><div class=""><br class=""></div><div class="">Second:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">if foo != nil { </font></div></div><div class=""><font face="Menlo" class=""> </font><span style="font-family: Menlo;" class="">// Using ? to be extra cautious, if foo is var</span></div><div class=""><div class=""><font face="Menlo" class=""> foo?.doSomething() </font></div></div><div class=""><div class=""><font face="Menlo" class="">}</font></div></div></blockquote><div class=""><br class=""></div><div class="">This again currently produces an error:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">let foo = Bar()</font></div></div><div class=""><div class=""><font face="Menlo" class="">foo?.doSomething() // ERROR</font></div></div></blockquote><div class=""><br class=""></div><div class="">Which is generally, what would semantically happen - the variable would loose it optionality. Or am I wrong?</div><div class=""><br class=""></div><div class="">Which would require migration, where within all scopes, where you check if a a variable is not nil, it removes all ? and !...</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>