<div dir="ltr">Correct me if I am wrong, but it seems like the main intended use of optionals would be to work with legacy Obj-C code that is missing nullability specifiers. In the rest of the cases, a forced-unwrap is just "syntactic sugar" for a fatal error block or a way to indicate that you have already checked the type using "as" or "!= nil" (ie. that they wrote the code in a non-Swift style and haven't updated it yet - just the perfect situation for a warning).<div><br></div><div>Another use is interoperability with "C" code, where the user knows that the code does not return a "null" pointer but has no way of annotating that in C. Or with arrays where the result is optional, but never is when the index is right. Maybe an @allowsForceUnwrap annotation on the function could silence this warning. Definitely a much more serious a condition that where the result of the function call goes unused.<br><div><div><br></div><div>A simple condition that a warning is emitted, except when unwrapping NSObject and its subclasses, or other unsafe operations like UnsafePointer, should cover all of its non-syntax uses. I think it is fair to say that developers would want to see the fatalError() written out.</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-07 13:36 GMT-05:00 Elijah Johnson <span dir="ltr"><<a href="mailto:ejrx7753@gmail.com" target="_blank">ejrx7753@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How about the proposal of warnings and/or fix-it for unnecessary use of optionals?<div><br></div><div>It seems to me though, that there aren't too many "necessary" uses for forced-unwrapping. Judging from (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0054-abolish-iuo.md</a>)<wbr>, it was probably added as a way of helping work with Obj-C also.</div><div><br></div><div>func test(a:String?) -> String {</div><div> return a!</div><div>}</div><div><div class="gmail_extra"><br></div><div class="gmail_extra">is equivelent to </div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>func test(a:String?) -> String {</div><div> if let a = a {</div><div> print(a);</div><div> } else {</div><div> fatalError();</div><div> }</div><div>}</div><div><br></div><div>I wouldn't remove it at this stage, but to quote (<a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>commonly_proposed.md</a>), it is "favoring terseness over clarity by introducing new magic syntactic sugar," ironically adding this very terse and easy syntax for the coding style that we do not want to incentivize.</div><div><br></div><div>Adding warnings and a fix-it to make the crash explicit would more or less be as good as removing forced-unwrap from the language. Just maybe needs some clarification of what exactly is a valid use of the force-unwrap. Maybe for interop with Obj-C it should be considered "necessary", for example.</div><div><br></div><div class="gmail_quote">2017-03-07 11:54 GMT-05:00 Josh Parmenter <span dir="ltr"><<a href="mailto:jparmenter@vectorform.com" target="_blank">jparmenter@vectorform.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Mar 6, 2017, at 7:52 PM, Elijah Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><mai<wbr>lto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><wbr>> wrote:<br>
<br>
Says: Fix it: Insert !<br>
Should say: Fix it: Use optional binding.<br>
<br>
I agree with this in general. I tell people that I’m teaching that unwrapping uses ‘!' for a reason. It should scream at you that something is happening that probably needs more careful attention.<br>
<br>
Best,<br>
Josh<br>
<br>
<br>
Joshua Parmenter | Engineering Lead, Apple Technologies<br>
<br>
T <a href="tel:248%20777%207777" value="+12487777777" target="_blank">248 777 7777</a><br>
C <a href="tel:206%20437%201551" value="+12064371551" target="_blank">206 437 1551</a><br>
F <a href="tel:248%20616%201980" value="+12486161980" target="_blank">248 616 1980</a><br>
<a href="http://www.vectorform.com" rel="noreferrer" target="_blank">www.vectorform.com</a><<a href="http://www.vectorform.com/" rel="noreferrer" target="_blank">http://www.<wbr>vectorform.com/</a>><br>
<br>
Vectorform<br>
2107 Elliott Ave Suite 303<br>
Seattle, WA 98121 USA<br>
<br>
Think Tank. Lab. Studio.<br>
We invent digital products and experiences.<br>
<br>
SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD<br>
<br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>