<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br></div><div>On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> ha scritto:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">Finally, there’s a woolier justification: there’s an often-touted misconception out there that force unwraps are bad, that they were only created to accommodate legacy apps, and that force-unwrapping is always bad and you should never do it. This isn’t true – there are many good reasons to use force unwrap (though if you reaching for it constantly it’s a bad sign). Force-unwrapping is often better than just whacking in a default value or optional chaining when the presence of nil would indicate a serious failure. Introduction of the `!!` operator could help endorse/encourage the use of “thoughtful” force-unwrapping, which often comes with a comment of the reasoning why it’s safe (of why the array can’t be empty at this point, not just that it is empty). And if you’re going to write a comment, why not make that comment useful for debugging at the same time.</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">If one could still just "!" I'm not sure that the "!!" would really encourage a more thoughtful force unwrapping. Almost every crash related to a force unwrap that I see from Swift beginners is 100% due to the fact that adding and exclamation point makes the code compile, so they add it.</div><div class=""><br class=""></div><div class="">Also, I strongly disagree with your statement that the idea that force-unwraps are bad is a misconception: if something is Optional, there's a reason why it is, otherwise it would not be Optional at all, and that's the reason why Optional exists in Swift and represents a substantial technological advancement over Objective-C. Using an Optional means that we are actually adding a thoughtful information to an instance: it could be there, or it could not, and that's perfectly fine. Crashing an app in production for a force-unwrap results in the poorest user experience ever, and it should never happen.</div></div></blockquote><div><br></div><div>If forced unwraps are only used in instances where you specifically expect the optional to not be nil, it is essentially sugar for a guard with preconditionFailure: it is used to enforce invariants the app should never break. It is very similar to a trap when accessing an out of bounds index in an array. In those cases, I actually prefer it crashing than having the app silently fail for the user, and you never finding out.</div><div><br></div><div>I try to limit my use of optional unwrapping but there are sometimes quite useful. IMHO, they are not inherently bad, but can be badly used.</div><br><blockquote type="cite"><div><div class="">I feel compelled to link another article, where Soroush Khanlou shows that sometimes the bare semantics of an Optional (that is, something is there or not) is not enough: <a href="http://khanlou.com/2017/03/that-one-optional-property/" class="">http://khanlou.com/2017/03/that-one-optional-property/</a></div><div class=""><br class=""></div><div class="">I also disagree with the idea that the "?? fatalError()" alternative suffers from cognitive dissonance, for the following reasons:</div><div class=""><br class=""></div><div class="">- on the right of the "??" operator there could be both an Optional or a non-Optional, which would result in a different type for the resulting instance;</div><div class="">- fatalError() by itself is an operation that changes the meaning of a function, making it non-total, and its very name conveys a clear meaning to a person that reads the code, thus it really doesn't seem to me that "?? fatalError()" could be misinterpreted;</div><div class=""><br class=""></div><div class="">Anyway, it would be interesting to consider "!! message" as an alternative to "!", thus forcing the user to at least do extra effort: that could discourage a light use of !.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Elviro</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>