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

[Xiaodi Wu]

That is plainly contrary to what the proposal says. It is to be sugar for a
string argument to fatalError, which would be read: "x, which fails iff y."
On Wed, Jun 28, 2017 at 23:35 Paul Cantrell <cantrell at pobox.com> wrote:

> On Jun 28, 2017, at 10:49 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Wed, Jun 28, 2017 at 10:33 PM, Paul Cantrell <cantrell at pobox.com>
> wrote:
>
>>
>> On 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.
>>
>>
>> Fine, then:
>>
>>     let paramData = params.data(using: String.Encoding.ascii) !!
>> “params must be URL-escaped, and thus ASCII"
>>
>> …or format the runtime message to fit that style of phrasing:
>>
>>     fatal error: unexpectedly found nil while unwrapping an Optional value
>>     Failing underlying assumption:
>>         params is URL-escaped, thus already ASCII
>>     Current stack trace:
>>         …
>>
>> 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 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.
>>
>>
>> Yes, of _course_ it’s not what the LHS is actually asserting. That is
>> precisely the point of having a message. There is pertinent information not
>> already present in the code.
>>
>
> See below.
>
>
>> The message describes an invariant not captured by the type system. In
>> other words, the author of this code believes they have guaranteed
>> something that the compiler itself cannot check. Thus this statement is
>> exactly backwards:
>>
>> You **absolutely cannot** proceed from this point in the code assuming
>> that `paramData` is a URL-escaped string.
>>
>>
>> The author of this code is telling you they have _already_ proceeded from
>> this point assuming that `paramData` is URL-escaped.
>>
>
> No, the author proceeded from a previous point assuming that `params` is
> URL-escaped. The act of unwrapping does not demarcate the transition
> between where `params` is assumed to be URL-escaped and where it is not.
>
>
> Well duh. But that’s not what the message conveys.
>
> Read x !! y as “x! /* which is guaranteed to succeed because y */”.
>
> P
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170629/1702ce0c/attachment.html>