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

[Xiaodi Wu]

On Wed, Jun 28, 2017 at 9:50 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> 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.
>

At the risk of belaboring the point, allow me to develop this intuition
further. The second argument in a precondition is classically phrased "X
must be Y" or "X is not Y," and it serves two purposes (as I understand
it). If the precondition fails, then the reader understands that it is
because X is not Y. If the precondition succeeds, the reader is assured
that the precondition has tested that X is in fact Y.

Two uses have been advanced for the RHS of the proposed operator. The first
is, in the case of failure, to explain the failure without requiring
surrounding code context. The second is to explain to the reader, in the
context of the code, why success should be assured. But, this does not
imply that the underlying reason why success is assured is in turn also
true if the force unwrapping operation succeeds.

_The only error message_ that satisfies both of the purposes of a
precondition message in the case of a force unwrap is "X is not nil." In
your example, "params must be URL-escaped" cannot fulfill both of these
uses, because successful unwrapping is not preconditioned on params being
in fact URL-escaped. OTOH, "params must be ASCII-encoded" is not necessary
as a message because it is implied in the meaning of `!`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170628/b5815aa3/attachment.html>