<div dir="ltr">On Wed, Jun 28, 2017 at 8:18 PM, Ben Cohen <span dir="ltr">&lt;<a href="mailto:ben_cohen@apple.com" target="_blank">ben_cohen@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span class=""><div>On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_9027869044708025685Apple-interchange-newline"></span><span 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">In the initial example, repeated here in largely identical form, the desired comment is &quot;array must be non-empty.&quot; In what way does that provide more information than a bare `!`?</div><br class="m_9027869044708025685Apple-interchange-newline"></div></span></blockquote></div><br><div>By the same token, why does precondition have an optional string? Why would you ever want to write more than:</div><div><br></div><div>precondition(!array.isEmpty)</div><div><br></div><div>It’s self evident – the array must not be empty! Why the second argument?</div></div></blockquote><div><br></div><div>In the case of `!array.isEmpty`, I would never use the second argument precisely because that condition is self-documenting. As to the larger question of why `precondition` is overloaded to take a second argument, my understanding--reflected in how I use it--is that it is useful when the meaning of the precondition is less than glanceable and cannot (without significant effort on the part of the reader) reveal a human-readable explanation as to _why_ the precondition might fail. However, as I mentioned, the act of unwrapping an optional and the reason why a function would return nil _are intended to be obvious, per the design rationale given in Swift project documents_.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Because you might want a meaningful string to be output when the app traps. And it gives you somewhere to document <i>why</i> it mustn’t be empty – the explanation for the precondition rather than the precondition itself. Similarly, when your app traps because of an unwrapped nil, it’s desirable to get some output in your debug console telling you why straight away, rather than have to hunt down the code, read the line that failed, then read the context around the line, to understand the reason. This is even more important if you didn’t write this code yourself.</div></div></blockquote><div><br></div><div>I would like to see an example where this string plausibly makes the difference between having to hunt down the code and not have to do so. I do not believe that &quot;array must not be empty&quot; or &quot;array guaranteed non-empty&quot; is such an example, and I cannot myself imagine another scenario where it would make such a difference.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>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><br></div><div>In cases where it’s really not necessary, ! would remain just like, when you’re not really too fussed, you can leave off the string from a precondition.</div></div></blockquote><div><br></div><div>I am not sure this second argument is a winning one, in that it does nothing to convince me that the RHS string is necessary. If the issue to be addressed is that `!` is used too lightly and without thought, an equally optimal result would be achieved by devising a new postfix operator `!!!`, to be named the &quot;thoughtful force-unwrapping operator,&quot; which is purely a synonym for `!`.</div></div><br></div></div>