<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 29, 2017 at 12:45 PM, Elviro Rocca via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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></blockquote><div><br></div><div>Well, a persisted inconsistency is worse than a crash :P</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>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><br></div><div>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><br></div><div><br></div><div>Elviro</div><div><div class="gmail-h5"></div></div></div></blockquote></div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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"><br></div><div style="font-size:12.8px">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"><br></div><div style="font-size:12.8px">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"><br></div><div style="font-size:12.8px">Instead of writing this (the original example, which by the way has a typo :P):</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div style="font-size:12.8px"><div style="font-size:12.8px"><font face="Menlo">guard !lastItem.isEmpty else { return }</font></div><div style="font-size:12.8px"><font face="Menlo">let lastItem = array.last !! "Array must be non-empty"</font></div></div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I would just write this:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div style="font-size:12.8px"><div style="font-size:12.8px"><font face="Menlo">guard </font><span style="font-family:Menlo;font-size:12.8px">let lastItem = array.last</span><font face="Menlo"> else { return }</font></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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"><br></div><div style="font-size:12.8px">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"><br></div></div></div><div style="font-size:12.8px">--</div><div style="font-size:12.8px">Víctor Pimentel</div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>