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

[Xiaodi Wu]

On Wed, Jun 28, 2017 at 8:54 PM, Paul Cantrell <paul at bustoutsolutions.com>
wrote:

>
> On Jun 28, 2017, at 8:32 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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.
>
>
> You needn’t imagine. There was one up-thread:
>
>   let paramData = params.data(using: String.Encoding.ascii)!
>
> Huh? Why is force unwrap safe here? OK, the code plainly says the author
> thinks that `params` must already be ASCII, but why is that a safe
> assumption? What reasoning lead to that? What other sections of the code
> does that reasoning depend on? If we get a crash on this line of code, what
> chain of assumptions should we follow to discover the change that broke the
> original author’s reasoning behind the force unwrap?
>
> This is a job for a comment:
>
>   let paramData = params.data(using: String.Encoding.ascii)!  // params
>  is URL-escaped, thus already ASCII
>
> Aha, it’s URL escaped.
>
> That comment does not repeat information already stated in the code
> itself. It does what any good comment does: it explains intent, context,
> and rationale. It doesn’t restate _what_, but rather explains _why_.
>
> For those who appreciate comments like that, this proposal simply allows
> them to surface at runtime:
>
>   let paramData = params.data(using: String.Encoding.ascii) !! "params is URL-escaped,
> thus already ASCII"
>
> And those who see no value in such a runtime message — and thus likely
> also see no value such a comment — are free not to use either.
>

If this is the most convincing example, then I'd actually be adamantly
_against_ such an operator (where now I'm merely skeptical and would like
to see evidence of usefulness). This example is, quite simply, _wrong_.
Here's why:

First, if force unwrapping fails, the message should explain why it failed:
the reason why it failed is _not_ because it's URL-escaped and _not_
because it's ASCII, but rather because it's **not** ASCII.

Second, even supposing the wording were fixed, it's at best not more useful
than `!` and at worst misleading. If the error message is "params not
ASCII-encoded" then it restates the code itself. If the error message is
"params not URL-escaped," then it's misleading, as that's not at all what
the LHS is actually asserting: it can be unwrapped *whether or not* it's
URL-escaped and it only matters that it's ASCII. You **absolutely cannot**
proceed from this point in the code assuming that `paramData` is a
URL-escaped string.



> Cheers,
>
> Paul
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170628/5bca166b/attachment.html>