On Wed, Jun 28, 2017 at 8:18 PM, Ben Cohen <[email protected]> wrote:
> > On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > In the initial example, repeated here in largely identical form, the > desired comment is "array must be non-empty." In what way does that provide > more information than a bare `!`? > > > By the same token, why does precondition have an optional string? Why > would you ever want to write more than: > > precondition(!array.isEmpty) > > It’s self evident – the array must not be empty! Why the second argument? > 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_. > Because you might want a meaningful string to be output when the app > traps. And it gives you somewhere to document *why* 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. > 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 "array must not be empty" or "array guaranteed non-empty" is such an example, and I cannot myself imagine another scenario where it would make such a difference. > 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. > > 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. > 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 "thoughtful force-unwrapping operator," which is purely a synonym for `!`.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
