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

[Víctor Pimentel Rodríguez]

On Thu, Jun 29, 2017 at 12:45 PM, Elviro Rocca via swift-evolution <
swift-evolution at swift.org> wrote:

> From the user's standpoint, a crash is the worst thing possible, and
> should always be avoided. A failure doesn't need to be silent for user, the
> app can still communicate that there was an error with some kind of human
> readable message, and the developer can still be informed via any service
> that provides logging of non-fatal errors (there are many, most of them
> free).
>

Well, a persisted inconsistency is worse than a crash :P

During development, a crash can be informative, and that's what "assert"
> and things like that are for: even if I still prefer to not crash, and
> handle invariants by using specifically crafted types, I can understand the
> need for crashing in development, and from that standpoint I'd definitely
> support a proposal which goal is to make crashes caused by forced
> unwrapping more informative for the developer, or to force the developer to
> make them more informative (by substituting "!" with "!!").
>
> The reason why I'm not completely convinced is the fact that there's
> already "fatalError", and its presence already clearly indicates in the
> code that something could trap there, in a verbally-appropriate way. In
> this sense a new operator could encourage practices that in my opinion
> should not be encouraged.
>
>
> Elviro
>

To me this !! operator does not add enough value to put it in the standard
library. The existing force unwrap operator already works fine, and if
Never is really going to be a bottom type, then I don't know in which cases
the !! operator would be better.

Actually, for me it would be worse, because you could only call it with a
String or a function that returned a String. What happens if I want to call
a method that does some housekeeping and then ends with a fatalError? I
could not use the !! operator unless that method returns a String.

And finally, I would not want to find such code in a project with multiple
people involved, as my personal experience is that a single ! leads to
crashes in production sooner or later, and if you track such crashes it
would not be obvious why they happen. If that code is written by one person
and will not be published anywhere, I suppose you can use it, but either in
open source projects or in teams, I would avoid that operator like hell.

Instead of writing this (the original example, which by the way has a typo
:P):

guard !lastItem.isEmpty else { return }
let lastItem = array.last !! "Array must be non-empty"

I would just write this:

guard let lastItem = array.last else { return }

The first example seems reasonable enough: you know that the array is
empty, you just checked for it! But that array may possible be a property
of a class and it can be changed in another thread, so you can't be so
sure. And because software is usually never finished, some other team mate
can add more code between the first line and the second line, making it
easier to inadvertently change the array contents and thus not preserving
the initial invariants. The second example may need to be rewritten if the
requirements change, but it does not have the same drawbacks as the initial
example and, well, it's definitely less code and easier to read.

Anyway, can we provide a real world example? If some projects are already
defining this operator, working examples must exist and we can analyze how
this operator affects the code and which patterns are leveraged by it.

--
Víctor Pimentel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170629/71912c65/attachment.html>