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

[Xiaodi Wu]

On Wed, Jun 28, 2017 at 9:50 PM, Alan Westbrook <alan at rockwoodsoftware.com>
wrote:

>
> On Jun 28, 2017, at 6:38 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Sorry, I fail to see how either wording enhances the expression of why
> this operation is taking place. The entire explanation seems self-evident
> to me in `!`.
>
>
> It may not be though. How many times have you seen a force unwrap and
> immediately thought the programmer to just be lazy, or new to Swift?
>

Never. (Now ask me what I immediately think of programmers who assert that
force unwrapping is a code smell...)

The !! syntax proposal at least makes these forces clearly an intentional
> and thought out endeavor.
>

As I wrote, if that's the objection, then we might as well simply coin a
new operator spelled `!!!`, identical in behavior to `!` but called the
"intentional and thought-out force-unwrapping operator." Equally, it'd be
an argument to retire postfix `!` and to introduce an infix `!` which
mandates an explanation.

This is actually, on rethink, a diametrically opposite argument to the
first one posed by Ben Cohen. That argument claims that there's sometimes a
need to explain the context of a force-unwrap with a human-readable
rationale; just like there's room for a one-argument precondition and a
two-argument precondition, there should be room for a two-argument
force-unwrap. Here, there's a claim that people assume all force-unwrapping
to be poorly thought out without a human-readable rationale. This is,
again, really an argument that there is no good unannotated force-unwrap.

I reject both these notions. Having seen the examples given above, I'm now
leaning towards the conclusion that there is nothing in the way of
explanation in a string that can usefully elaborate upon the very
unambiguous statement that is a force unwrap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170628/9d4a91d3/attachment.html>