[swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Xiaodi Wu]

On Wed, Jun 28, 2017 at 8:18 PM, Ben Cohen <ben_cohen at apple.com> wrote:

>
> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> 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 `!`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170628/6148502f/attachment.html>