<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><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Well, a persisted inconsistency is worse than a crash :P</div></div></div></div></blockquote><div><br class=""></div><div>I still strongly disagree with this, I'm sorry. Inconsistent data is an orthogonal problem to fatal errors, and a crash is basically a middle finger to the user. </div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_signature"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" style="font-size:12.8px" class=""><div style="font-size:12.8px" class="">To me this !! operator does not add enough value to put it in the standard library. The existing force unwrap operator already works fine, and if Never is really going to be a bottom type, then I don't know in which cases the !! operator would be better.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Actually, for me it would be worse, because you could only call it with a String or a function that returned a String. What happens if I want to call a method that does some housekeeping and then ends with a fatalError? I could not use the !! operator unless that method returns a String.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">And finally, I would not want to find such code in a project with multiple people involved, as my personal experience is that a single ! leads to crashes in production sooner or later, and if you track such crashes it would not be obvious why they happen. If that code is written by one person and will not be published anywhere, I suppose you can use it, but either in open source projects or in teams, I would avoid that operator like hell.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Instead of writing this (the original example, which by the way has a typo :P):</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class=""><div style="font-size:12.8px" class=""><div style="font-size:12.8px" class=""><font face="Menlo" class="">guard !lastItem.isEmpty else { return }</font></div><div style="font-size:12.8px" class=""><font face="Menlo" class="">let lastItem = array.last !! "Array must be non-empty"</font></div></div></div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">I would just write this:</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class=""><div style="font-size:12.8px" class=""><div style="font-size:12.8px" class=""><font face="Menlo" class="">guard </font><span style="font-family:Menlo;font-size:12.8px" class="">let lastItem = array.last</span><font face="Menlo" class=""> else { return }</font></div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">The first example seems reasonable enough: you know that the array is empty, you just checked for it! But that array may possible be a property of a class and it can be changed in another thread, so you can't be so sure. And because software is usually never finished, some other team mate can add more code between the first line and the second line, making it easier to inadvertently change the array contents and thus not preserving the initial invariants. The second example may need to be rewritten if the requirements change, but it does not have the same drawbacks as the initial example and, well, it's definitely less code and easier to read.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Anyway, can we provide a real world example? If some projects are already defining this operator, working examples must exist and we can analyze how this operator affects the code and which patterns are leveraged by it.</div><div style="font-size:12.8px" class=""><br class=""></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br class=""></div><div>I agree with most of this, but I think the contraposition here is with:</div><div><br class=""></div><div>guard let lastItem = array.last else { fatalError() }</div><div><br class=""></div><div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">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 class=""><br class=""></div><div class=""><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></div></div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><br class=""></div></div></div></div></div></div><div>Swift is a language that doesn't enforce a particular style over the other (thankfully) so the standard library includes many constructs that can end up being mostly ignored by some people in some projects.</div><div><br class=""></div><div>Because of that, I don't think that we should add to the standard library a particular construct just because some people use it in third party libraries, if the same behavior can be already accomplished with very minimal code using what's already there.</div><div><br class=""></div><div>Also, avoiding all crashes in production is to me a fundamental value of software development, and is not particularly related to Swift or iOS or whatever. In fact, as was already written some posts before, logic errors are either mistakes or are used to avoid additional checks in cases when the overhead introduced by those checks is not acceptable from a performance standpoint, which is a very unfrequent case.</div><div><br class=""></div><div>Now, during development I can decide to make something crash for informative reasons, so in general I'm not opposed at all to those constructs, but that doesn't justify production code that crashes due to implicit unwrapping or out-of-bounds errors. That's my opinion, and it's also my opinion that trusting a linter is a much weaker solution than actually enforcing the type-system and the compiler, and I'd say that Swift is not Objective-C or PHP, but that's a completely different topic.</div><div><br class=""></div><div>Elviro</div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra">
</div></div>
</blockquote></div><br class=""></body></html>