<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 29 Jun 2017, at 12:37, Elviro Rocca <<a href="mailto:retired.hunter.djura@gmail.com" class="">retired.hunter.djura@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">From the user's standpoint, a crash is the worst thing possible, and should always be avoided. A failure doesn't need to be silent for user, the app can still communicate that there was an error with some kind of human readable message, and the developer can still be informed via any service that provides logging of non-fatal errors (there are many, most of them free).</div><div class=""><br class=""></div><div class="">During development, a crash can be informative, and that's what "assert" and things like that are for: even if I still prefer to not crash, and handle invariants by using specifically crafted types, I can understand the need for crashing in development, and from that standpoint I'd definitely support a proposal which goal is to make crashes caused by forced unwrapping more informative for the developer, or to force the developer to make them more informative (by substituting "!" with "!!").</div><div class=""><br class=""></div><div class="">The reason why I'm not completely convinced is the fact that there's already "fatalError", and its presence already clearly indicates in the code that something could trap there, in a verbally-appropriate way. In this sense a new operator could encourage practices that in my opinion should not be encouraged.</div></div></div></blockquote><div><br class=""></div><div>I understand your wish to never crash in production. But I think it’s an ideal that is quite far from the day to day development practices of many developers. If the philosophy of the Standard Library was to avoid all production crashes, we wouldn’t have the following:</div><div><br class=""></div><div><ul class="MailOutline"><li class="">Implicitly unwrapped optionals</li><li class="">Optional explicit unwrapping</li><li class="">fatalError</li><li class="">precondition</li></ul><div class=""><br class=""></div><div class="">The fact is that we have those tools and that they are useful and used. I salute your wish to ban all of the above in an effort to avoid all crashes in production, but IMHO, it’s a style that is best enforced using a linter.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Elviro</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Il giorno 29 giu 2017, alle ore 12:12, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> ha scritto:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><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=""><div class=""><br class=""><div class=""><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 class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" 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=""><div class=""><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" 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=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>